تصميم أنظمة المدفوعات الموثوقة: مفاتيح عدم التكرار، آلات الحالات، وضمانات الويب هوك

💳 Payment System: ماذا يحدث بعد الضغط على Pay Now؟

سؤال انترفيو شكله بسيط جدًا... لكنه يكشف هل أنت فاهم Payment Systems فعلًا أم لا.

المستخدم ضغط على زرار Pay Now... إيه اللي بيحصل؟

📚 Table of Contents

• السؤال
• الإجابة السريعة
• هل نخزن بيانات الكارت؟
• Payment Gateway
• Public Key vs Secret Key
• PCI DSS
• ماذا يحدث عند Pay Now؟
• Server-side Validation
• Payment Intent / Session
• Authorization و Capture
• 3D Secure و SCA
• ليه Success مش كفاية؟
• Network Failure
• Webhooks
• Webhook Security
• Raw Request Body
• Duplicate Webhooks
• Webhook Ordering
• Idempotency
• Double Payment
• Order State Machine
• Payment State Machine
• Database Transactions
• Payment Reconciliation
• Refunds
• Timeouts
• Retries
• Security Checklist
• Architecture
• Interview Answer
• Common Wrong Answers
• Production Checklist
• Official Sources

🎤 السؤال

الـinterviewer يقول لك:

User ضغط Pay Now. إيه اللي بيحصل؟

لو أول مرة تشتغل على Payment System، ممكن تتخيل:

User clicks Pay
       ↓
Money deducted
       ↓
Payment Success

لكن في production الموضوع أقرب إلى:

User
 ↓
Frontend
 ↓
Backend
 ↓
Payment Provider
 ↓
Payment Network / Bank
 ↓
Provider
 ↓
Webhook
 ↓
Backend
 ↓
Order / Subscription / Wallet

وفي كل سهم من دول ممكن تحصل مشكلة. 😂

⚡ الإجابة السريعة

التصميم المحترم غالبًا يكون:

1. User clicks Pay Now
2. Backend validates the order
3. Backend calculates the authoritative amount
4. Backend creates/reuses a payment object
5. Payment provider handles payment details
6. User completes payment / authentication
7. Provider processes the payment
8. Backend receives a verified webhook
9. Backend updates payment state
10. Backend fulfills the order

والـ3 كلمات اللي لازم تفضل فاكرهم:

Webhook
+
Idempotency
+
State Machine

💳 هل نخزن بيانات الكارت؟

غالبًا لا.

في تصميمات حديثة، بدل ما موقعك يجمع:

Card Number
Expiry
CVV

بنستخدم Payment Service Provider / Payment Gateway مثل:

Stripe
PayPal
Paymob
Adyen
Checkout.com

بحسب البلد والـbusiness requirements.

الفكرة إن الـpayment provider يتعامل مع أجزاء حساسة من عملية الدفع، بينما تطبيقك يتعامل مع:

Order
Customer
Amount
Payment State
Provider IDs
Business Logic

لكن خلي بالك:

استخدام Payment Provider لا يعني تلقائيًا أن كل مسؤوليات PCI اختفت.

طريقة integration نفسها تؤثر على نطاق ومتطلبات PCI DSS. الـPCI Security Standards Council يوضح مثلًا أن fully hosted payment pages أو بعض redirect/iframe implementations تختلف عن الحالات التي يكون فيها merchant website نفسه جزءًا من صفحة جمع بيانات البطاقة. citeturn3search0turn3search4

🏦 Payment Gateway

الـPayment Gateway / Payment Service Provider هو الطبقة التي تربط تطبيقك بمنظومة الدفع.

ممكن تتعامل مع:

Card Networks
Banks
Wallets
Alternative Payment Methods
3D Secure
Fraud Checks
Authorization
Capture
Refunds
Disputes

لكن التفاصيل تختلف من provider للتاني.

🔑 Public Key vs Secret Key

غالبًا هتلاقي credentials مثل:

Public / Publishable Key
Secret Key

الـpublic key يمكن استخدامه في client-side integration عندما يسمح provider بذلك.

أما:

Secret Key

فده server-side credential.

مينفعش تحطه في:

Frontend bundle
HTML
Public GitHub repo
localStorage
Client-side environment variable

Stripe تحذر صراحة من وضع secret keys في environment variables التي يتم تضمينها في ملفات الـfrontend؛ لأنها تصبح مرئية للزائر. citeturn2search1turn2search3

🛡️ PCI DSS

دي نقطة مهمة جدًا في interview.

مش معنى:

"أنا بستخدم Stripe"

إن:

"أنا خلاص مش مسؤول عن أي security."

الـPCI scope يعتمد على طريقة integration.

مثلاً:

Merchant
   ↓
Redirect
   ↓
Provider-hosted payment page

مختلف عن:

Merchant website
   ↓
Merchant-controlled payment form
   ↓
Provider

الـPCI SSC يوضح أن eligibility للـSAQ A تعتمد على أن عناصر payment page تأتي فقط من PCI DSS compliant third-party provider، بينما implementations التي يكون فيها merchant website مسؤولًا عن عناصر من payment page قد تدخل في نطاق مختلف. citeturn3search1turn3search7

يعني:

اختيار payment integration هو security + architecture decision.

🖱️ ماذا يحدث عند Pay Now؟

خلينا نمشي step by step.

1️⃣ User Clicks Pay

الـfrontend عنده:

Cart
Order
Customer
Payment Method

لكن أهم قاعدة:

الـfrontend لا يحدد السعر النهائي باعتباره مصدر الحقيقة.

مينفعش تبعت:

{
  "amount": 10
}

والسيرفر يقول:

حاضر، هخصم 10.

لا.

2️⃣ Server-side Validation

الـbackend لازم يتحقق من:

Order exists?
User owns order?
Order still payable?
Products still available?
Prices still valid?
Currency correct?
Discount valid?
Shipping valid?
Tax correct?
Amount correct?

ثم يحسب:

Final Amount

من البيانات الموثوقة عند السيرفر.

مثال:

Client says:
amount = $10

Database says:
order total = $25

الـbackend يستخدم:

$25

مش الـ$10 اللي جاي من frontend.

3️⃣ Create / Reuse Payment Object

في بعض providers، بدل ما تعمل "charge" مباشرة، بتنشئ object يمثل محاولة الدفع.

في Stripe مثلًا، PaymentIntent يمثل عملية الدفع خلال lifecycle الخاص بها، ويمكن أن يتعامل مع authentication الإضافي، كما توصي Stripe بإعادة استخدام نفس PaymentIntent عند استئناف checkout بدل إنشاء واحد جديد لنفس العملية، واستخدام idempotency key لمنع duplicate PaymentIntents. citeturn2search0

Conceptually:

Order
  ↓
PaymentIntent / Payment Session
  ↓
Payment Attempt

لكن اسم الـobject والflow يختلف حسب provider.

🧾 Payment Session

في بعض integrations، هتتعامل مع:

Checkout Session

أو object مشابه.

الفكرة:

Order #123
      ↓
Payment Session
      ↓
Customer payment

الـsession قد ترتبط بـ:

Amount
Currency
Order
Customer
Expiration
Payment Method
Provider ID

🔐 3D Secure و SCA

مش كل payment عبارة عن:

Card
↓
Success

أحيانًا البنك أو payment provider يطلب:

3D Secure
OTP
Biometric
Bank approval
Additional authentication

وده ممكن يغير حالة العملية إلى:

requires_action

أو حالة مشابهة حسب provider.

Stripe PaymentIntents مصممة للتعامل مع payment lifecycle وحالات authentication الإضافية مثل SCA. citeturn2search0

فلو الـfrontend شاف:

Payment not immediately successful

مش لازم معناها:

Payment failed

ممكن يكون:

Customer action required

🏦 Authorization vs Capture

دي نقطة interview ممتازة.

بعض payment systems تفرق بين:

Authorization

و:

Capture

Authorization

البنك يوافق على حجز/اعتماد المبلغ.

"المبلغ متاح"

لكن مش بالضرورة تم تحويله نهائيًا لك.

Capture

تطلب تحصيل المبلغ.

Authorization
      ↓
Capture
      ↓
Payment collected

مش كل integration تستخدم flow منفصل بالشكل ده؛ أحيانًا يتم authorization + capture في flow واحد.

❓ لو Payment Gateway رجع Error؟

هل معناها:

Money not deducted?

مش لازم.

ودي من أهم أفكار payment systems.

تخيل:

Your Server
   ↓
Provider
   ↓
Bank
   ↓
Money captured
   ↓
Network dies

أنت ممكن تستقبل:

Timeout

لكن البنك/المزود يكون نفذ العملية.

فالحالة الحقيقية:

Unknown

مش:

Failed

🚨 Network Failure

دي واحدة من أخطر الحالات.

مثلاً:

POST /pay
        ↓
Provider
        ↓
Bank approves
        ↓
Money captured
        X
Response lost

الـserver عندك يقول:

Timeout

لكن الحقيقة:

Payment = Successful

لو عملت retry عشوائي:

Retry payment

ممكن تخاطر بعملية دفع ثانية.

وهنا:

🔥 Idempotency

🔑 Idempotency

المعنى:

نفس logical payment request لو اتكرر، ماينشئش عملية دفع ثانية.

مثلاً:

POST /payments
Idempotency-Key: order_123_attempt_1

لو حصل:

Request
↓
Timeout

تقدر تعيد:

POST /payments
Idempotency-Key: order_123_attempt_1

والـprovider أو نظامك يتعامل معاه كـsame logical operation حسب الـidempotency semantics.

Stripe توثق أن idempotency keys تسمح بإعادة محاولة requests بأمان بعد connection errors دون إنشاء object ثاني بالخطأ، وتربط المفتاح بنتيجة الطلب الأول. citeturn2search4

💥 Double Payment

المستخدم ضغط:

Pay
Pay
Pay

أو:

Frontend retry
+
Network retry
+
Backend retry

لو كل واحدة عملت:

Create payment

ممكن توصل إلى:

Charge 1
Charge 2
Charge 3

وده nightmare. 😂

التصميم الأفضل يكون عنده:

Order ID
+
Payment Attempt ID
+
Idempotency Key
+
Provider Payment ID

ويقدر يربط العملية كلها ببعض.

🪝 Webhooks

وهنا ندخل لأهم جزء.

الـwebhook هو:

Provider
   ↓
POST
   ↓
Your Backend

يعني بدل ما أنت تعتمد فقط على نتيجة request الذي بدأ الدفع، الـprovider يبلغك عندما تحدث events مهمة.

مثلاً:

payment succeeded
payment failed
refund
chargeback
subscription payment

PayPal يصف webhooks بأنها HTTPS POSTs يرسلها إلى endpoint على سيرفرك عند حدوث events، ويؤكد أن التحقق من الرسالة ضروري لمعرفة أنها جاءت فعلًا من PayPal. citeturn0search2turn0search3

Stripe كذلك توصي بمراقبة webhooks لمعرفة اكتمال الدفع أو فشله بعد confirmation، وتوصي بمعالجة webhook events asynchronously. citeturn2search0turn2search11

🌐 Webhook Endpoint

مثلاً:

POST /api/payments/webhook

الـprovider يرسل:

{
  "event": "payment.succeeded",
  "paymentId": "pay_123",
  "orderId": "order_123"
}

لكن:

متصدقش الـJSON لمجرد إنه وصل.

🔐 Webhook Security

السؤال:

إيه اللي يمنع attacker يعمل:

POST /api/payments/webhook

ويبعت:

{
  "event": "payment.succeeded"
}

؟

الإجابة:

Webhook Signature Verification

الـprovider يرسل signature أو آلية تحقق مشابهة.

السيرفر:

Receive webhook
       ↓
Verify signature
       ↓
Valid?
  ├── No → Reject
  └── Yes
       ↓
Process event

PayPal توفر آلية رسمية للتحقق من webhook signature، سواء بالتحقق التشفيري محليًا أو باستخدام verification endpoint. citeturn0search1turn0search3

Stripe كذلك تستخدم signed webhook events، وتوضح أن تعديل body قبل التحقق قد يجعل signature verification يفشل. citeturn2search10

🧾 Raw Request Body

دي نقطة عملية مهمة جدًا.

بعض providers يعتمدون على:

Raw HTTP Body

في signature verification.

لو framework عمل:

JSON parse
↓
re-stringify

قبل verification، ممكن الـsignature ما تطابقش.

Stripe توضح أن webhook signature verification تحتاج raw, unmodified request body. citeturn2search10

يعني في implementation:

Receive raw body
      ↓
Verify signature
      ↓
Parse JSON
      ↓
Process

مش:

Parse
↓
Modify
↓
Verify

🔁 Duplicate Webhooks

هل الـprovider هيبعت webhook مرة واحدة فقط؟

متفترضش ده.

Stripe توضح أن webhook endpoint قد يستقبل نفس event أكثر من مرة، وتوصي بتسجيل event IDs التي تمت معالجتها وعدم إعادة معالجة event سبق تسجيله. كما توصي بمعالجة الأحداث asynchronously. citeturn2search11

يعني:

Webhook Event ID
        ↓
Already processed?
   ├── Yes → Ignore / acknowledge
   └── No
        ↓
Process
        ↓
Mark processed

🔀 Webhook Ordering

مشكلة أخرى:

ممكن الأحداث توصل بترتيب مختلف.

مثلاً:

refund

يوصل قبل:

payment succeeded

أو:

event A
event B
event C

توصل:

B
A
C

عشان كده متبنيش system يفترض إن network delivery order = business order.

اعتمد على:

Event timestamp
+
Provider object state
+
Your state machine

وبعض providers قد يتيحون retrieval للـcurrent state من الـAPI عند الحاجة.

🧠 Order State Machine

متخليش:

Order.status = "paid"

هو كل النظام.

فكر في states:

Pending
   ↓
Payment Pending
   ↓
Paid
   ↓
Fulfilled

أو:

Pending
 ├──→ Cancelled
 ├──→ Payment Failed
 └──→ Payment Pending
          ↓
        Paid
          ↓
      Processing
          ↓
       Shipped
          ↓
      Completed

ده يمنع إن webhook عشوائي يغير order لحالة غير منطقية.

💰 Payment State Machine

ممكن يكون عندك:

Created
   ↓
Pending
   ↓
Requires Action
   ↓
Authorized
   ↓
Captured

وممكن:

Pending
   ↓
Failed

أو:

Captured
   ↓
Refunded

حسب payment provider والـbusiness model.

🗄️ Database Design

ممكن يكون عندك:

Orders

id
user_id
total
currency
status

Payments

id
order_id
provider
provider_payment_id
amount
currency
status
idempotency_key
created_at
updated_at

Payment Events

id
provider
provider_event_id
payment_id
event_type
payload_hash
processed_at
created_at

والـprovider_event_id ممكن يكون عليه unique constraint لمنع duplicate processing.

🔒 Database Transactions

افترض webhook:

Payment succeeded

لازم تعمل:

Payment.status = Paid
Order.status = Paid

لكن لو واحدة نجحت والثانية فشلت؟

هنا تحتاج transaction حيثما كان ذلك مناسبًا:

BEGIN
 ↓
Update Payment
 ↓
Update Order
 ↓
Insert Event Log
 ↓
COMMIT

لكن خليك واعي:

transaction في DB لا تجعل external payment provider transaction جزءًا من نفس ACID transaction.

لأن البنك والـprovider خارج database بتاعتك.

🧩 External Side Effects

مثلاً بعد payment:

Mark order paid
Send email
Create invoice
Update inventory
Send notification

متعملش:

DB commit
+
10 external API calls

داخل نفس transaction.

فكر في:

DB state
+
Outbox
+
Async workers

للمهام الجانبية المهمة.

🔄 Payment Reconciliation

دي نقطة قوية جدًا في الـinterview.

ماذا لو:

Your webhook was lost

أو:

Your database was temporarily unavailable

أو:

Webhook processing failed

؟

لازم يكون عندك طريقة reconciliation.

مثلاً job دوري:

Every X minutes
       ↓
Find payments stuck in Pending
       ↓
Query provider
       ↓
Compare state
       ↓
Repair local state

يعني:

Webhook
+
Reconciliation

مش:

Webhook فقط

🔁 Retries

الـwebhook نفسه ممكن يفشل.

مثلاً:

Provider
 ↓
Webhook
 ↓
500 Internal Server Error

الـprovider قد يعيد delivery حسب provider policy.

PayPal مثلًا توضح أن non-2xx responses تؤدي إلى إعادة محاولة delivery حتى 25 مرة خلال 3 أيام، وفق توثيقها الحالي. citeturn0search2

لذلك:

Webhook handler

لازم يكون:

Fast
Reliable
Idempotent

ومتعملش فيه عملية ضخمة جدًا قبل ما ترد.

⏱️ Webhook Handler

تصميم جيد:

Receive
 ↓
Verify signature
 ↓
Check duplicate
 ↓
Persist event
 ↓
Return 2xx
 ↓
Process asynchronously

بدل:

Receive
 ↓
Generate invoice
 ↓
Send 5 emails
 ↓
Update 10 services
 ↓
Call another API
 ↓
Finally return 200

Stripe توصي بمعالجة webhook events asynchronously، وPayPal تعتمد على 2xx كإشارة نجاح للاستلام وتعيد المحاولة عند الفشل. citeturn2search11turn0search2

💸 Refund

الدفع مش نهاية lifecycle.

ممكن:

Paid
 ↓
Refund requested
 ↓
Refund processing
 ↓
Refunded

والـrefund نفسه ممكن ينتج event جديد.

فمتعتبرش:

Payment = immutable success

🚨 Chargeback / Dispute

في card payments ممكن يحصل:

Customer disputes transaction

فالنظام يحتاج يدعم حالات مثل:

Disputed
Under Review
Won
Lost

وده مهم جدًا في systems الحقيقية.

🧮 Amount Validation

من أخطر الأخطاء:

Frontend:
amount = 1

بينما:

Order total = 1000

الـbackend لازم يكون authoritative.

كمان انتبه لـ:

Currency
Decimal precision
Minor units
Rounding
Tax
Discount
Shipping

مثلاً بعض APIs تستخدم:

1099

بدل:

10.99

لتمثيل أصغر وحدة للعملة.

التفاصيل تعتمد على provider والعملة.

🧪 Payment Testing

متختبرش production ببطاقات حقيقية لمجرد التجربة.

استخدم:

Sandbox
Test Mode
Test Cards
Webhook Simulator

PayPal توفر Webhooks Simulator لاختبار webhook listeners، كما توفر بيئة sandbox لاختبار حالات الدفع. citeturn0search4turn0search7

واختبر scenarios مثل:

Success
Declined
Timeout
3DS required
Webhook duplicate
Webhook delayed
Webhook invalid signature
Refund
Chargeback
Network failure
Provider unavailable

🏗️ Architecture

flowchart LR
    U["User"]
    F["Frontend"]
    API["Backend API"]
    DB[("Database")]
    PG["Payment Provider"]
    BANK["Bank / Payment Network"]
    WH["Webhook Endpoint"]
    Q[["Queue"]]
    W["Worker"]
    S[("Object / Invoice Storage")]
    OBS["Logs / Metrics / Traces"]

    U --> F
    F -->|"Pay Now"| API
    API -->|"Validate Order"| DB
    API -->|"Create / Confirm Payment"| PG
    PG --> BANK
    BANK --> PG
    PG -->|"Payment Result"| F

    PG -->|"Signed Webhook"| WH
    WH -->|"Verify + Persist Event"| DB
    WH --> Q
    Q --> W
    W --> DB
    W --> S
    W --> OBS

    API --> OBS
    WH --> OBS
    PG --> OBS

🔄 Full Payment Flow

User
 ↓
Pay Now
 ↓
Frontend
 ↓
Backend
 ↓
Validate Order
 ↓
Calculate Amount
 ↓
Create / Reuse Payment
 ↓
Payment Provider
 ↓
Bank / Network
 ↓
Authentication if required
 ↓
Provider updates payment state
 ↓
Webhook
 ↓
Verify Signature
 ↓
Deduplicate Event
 ↓
Persist Event
 ↓
Queue Processing
 ↓
Update Payment
 ↓
Update Order
 ↓
Fulfill Order
 ↓
Notify User

🧠 نقطة مهمة جدًا

الـfrontend ممكن يشوف:

success

لكن الـbackend لازم يكون عنده مصدر موثوق للحالة النهائية.

وفي integrations مثل Stripe، توثيق PaymentIntents يوصي بمراقبة webhooks بعد confirmation لمعرفة أن الدفع اكتمل أو فشل. citeturn2search0

يعني:

Frontend Success Screen

مش هو نفسه:

Backend Financial Truth

🔐 Security Checklist

• Secret keys server-side only
• HTTPS everywhere
• Verify webhook signatures
• Preserve raw webhook body when required
• Don't trust frontend amount
• Don't trust frontend payment status
• Validate order ownership
• Idempotency keys
• Unique provider event IDs
• Don't log card data
• Don't store unnecessary cardholder data
• Secure payment integration
• Short-lived download/payment links where appropriate
• Audit payment events
• Rate-limit public endpoints
• Monitor suspicious activity

❌ Common Wrong Answers

❌ "هعمل API /pay والـprovider يرجع success وخلاص"

المشكلة:

Timeout
+
Webhook
+
Duplicate
+
Async states

❌ "لو request failed يبقى payment failed"

غلط.

ممكن:

Payment succeeded
+
Response lost

❌ "لو frontend قال success يبقى order paid"

غلط.

الـfrontend مش financial authority.

❌ "Webhook endpoint public يبقى أي حد يقدر يبعت"

الـendpoint لازم يكون reachable من provider، لكن الرسالة نفسها لازم تتوثق.

❌ "هعمل webhook وأحدث order مباشرة"

لازم:

Verify
+
Deduplicate
+
Validate state transition

❌ "هستخدم paymentId كـidempotency"

مش بالضرورة.

لازم تفرق بين:

Payment ID
Provider Event ID
Idempotency Key
Order ID
Payment Attempt ID

كل واحد له وظيفة مختلفة.

❌ "هخزن رقم الكارت عشان أسهل"

غالبًا تصميم سيئ جدًا وممكن يوسع PCI/security scope بشكل خطير.

🎯 Interview Answer

لو الـinterviewer قال:

"User ضغط Pay Now. إيه اللي بيحصل؟"

ممكن تجاوب:

"أول حاجة مش هثق في الـfrontend في السعر أو حالة الـorder. الـbackend هيتأكد إن الـorder صالح، وإن المستخدم مالكه، وهيحسب المبلغ من server-side data. بعد كده هعمل أو أعيد استخدام payment object عند الـpayment provider، مع idempotency عشان لو حصل retry أو double click مايحصلش duplicate charge. الـcustomer يكمل الدفع وقد يحتاج 3D Secure أو authentication إضافي. بعد كده مش هعتمد فقط على نتيجة الـHTTP request، لأن ممكن يحصل timeout بعد ما البنك أو الـprovider نفذ العملية. هعتمد على signed webhook لتأكيد الأحداث، وأتحقق من signature، وأمنع duplicate webhook processing باستخدام event ID أو provider-specific identifier. بعد كده أسجل payment state وأحدث order state بشكل transactional داخل الـDB، وأستخدم queue للـside effects الثقيلة. وكمان هعمل reconciliation job للحالات اللي تفضل pending بسبب فقدان webhook أو مشاكل الشبكة. وأخزن provider payment ID وidempotency key وكل الأحداث المهمة عشان أقدر أعمل audit وdebugging."

دي إجابة فيها:

Payment Integration
+
Security
+
Distributed Systems
+
Reliability
+
Idempotency
+
Webhooks
+
Database Design
+
State Machines
+
Observability

وده الفرق بين:

Developer who calls a payment API

و:

Engineer who designs a payment system

🏆 Production Checklist

Order

• Server calculates total
• Order ownership verified
• Inventory checked
• Order state validated

Payment

• Provider payment ID stored
• Idempotency key
• Currency validated
• Amount validated
• Payment state machine

Webhook

• HTTPS
• Signature verification
• Raw body preserved if required
• Duplicate event protection
• Fast acknowledgment
• Async processing
• Retry handling

Database

• Payment table
• Payment events table
• Unique provider event ID
• Audit trail
• Transaction boundaries
• Outbox where appropriate

Recovery

• Reconciliation job
• Stuck payment detection
• Provider status lookup
• Refund handling
• Dispute handling

Observability

• Payment success rate
• Payment failure rate
• Webhook failure rate
• Webhook latency
• Duplicate events
• Pending payments
• Refund rate
• Provider errors
• Correlation IDs

🧠 Mental Model

احفظها كده:

Don't Trust the Client
        ↓
Validate on Server
        ↓
Create / Reuse Payment
        ↓
Use Idempotency
        ↓
Provider Processes Payment
        ↓
Don't Assume Request Result = Final Truth
        ↓
Verify Webhook
        ↓
Deduplicate Event
        ↓
Update State
        ↓
Reconcile Failures

وأهم سؤال تسأله لنفسك:

"ماذا يحدث لو البنك خصم الفلوس، لكن الـresponse ضاع قبل ما يوصلني؟"

لو إجابتك:

"هعمل retry وخلاص."

🚨 مشكلة.

لو إجابتك:

"هستخدم idempotency، وأعتمد على provider state/webhook، وأمنع duplicate processing، وعندي reconciliation للحالات المعلقة."

أنت بدأت تفكر فعلًا كمهندس Payment System. 💳

📚 Official Sources

Stripe

• Stripe — Payment Intents API
• Stripe — Idempotent requests
• Stripe — Webhooks
• Stripe — Webhook troubleshooting / signature verification
• Stripe — API keys
• Stripe — Checkout

PayPal

• PayPal — Webhooks overview
• PayPal — Webhook integration and verification
• PayPal — Verify webhook signature
• PayPal — Webhooks simulator

PCI Security Standards Council

• PCI SSC — Direct Post vs iFrame / URL Redirect
• PCI SSC — SAQ A vs SAQ A-EP
• PCI SSC — Embedded payment pages and SAQ A
• PCI SSC — Current SAQ A e-commerce criteria

💳 Payment is not just an API call.

Validate → Pay → Verify → Deduplicate → Reconcile

That's Payment Engineering.