egypt-payment-guardian

Egypt Payment Guardian

Mission

Use this skill for Egypt payment integrations where provider redirects, callbacks, signatures, currency handling, and duplicate events can break production. Treat the provider reference files as source-linked field notes, not a replacement for official docs.

Decision Path

Always follow this order:

1. Identify the provider, integration path, environment, and payment method.
2. Load the provider reference and any shared pattern that matches the risk.
3. Confirm the server boundary and list secret env var names only.
4. Verify the provider authenticity signal: HMAC, signature, SecureHash, webhook signature, or documented server-side inquiry.
5. Compare local order reference, provider reference, amount, currency, and status fields.
6. Store the provider event/reference idempotently before fulfillment.
7. Fulfill only from verified server-side state.
8. Add tests or manual QA for duplicate events, invalid signatures, delayed callbacks, and stale state.

Non-Negotiables

• Treat all money movement as high risk.
• Never fulfill from a browser redirect, hosted checkout result, SDK callback, or frontend-only status alone.
• Verify provider signatures, HMACs, or secure hashes exactly as documented.
• Keep merchant credentials, HMAC secrets, secret keys, and service role keys server-side only.
• Compare provider amount, currency, order reference, and transaction reference before creating paid state.
• Make callbacks, webhooks, retries, inquiry responses, and page refreshes idempotent.
• Store provider event/reference uniqueness before activating subscriptions, enrollments, bookings, credits, or invoices.
• Log safe identifiers only: order id, provider reference, status, timestamp. Never log tokens, card data, signatures, HMAC secrets, or raw credentials.

Required Audit

Before implementing or reviewing payment code, identify:

1. Provider and integration path.
2. Sandbox/test vs live environment.
3. Amount unit and currency rules.
4. Server endpoint receiving callbacks or webhooks.
5. Signature/HMAC/SecureHash method and raw-body requirements.
6. Unique payment, order, event, and provider reference fields.
7. Status mapping for pending, paid, failed, cancelled, expired, refunded, voided, and duplicate.
8. Ordering behavior when callback/webhook arrives before or after client redirect.
9. What happens on duplicate callback, retry, refresh, refund, void, missing user, or missing order.
10. Env var names by name only, never values.