Checkout

Authorization, capture, and refund flows for an e-commerce checkout API.

Sam Rivera Product All APIs must use TLS 1.2+. Fraudulent card-not-present attempts. Velocity checks and 3DS when required. Payment API remains available during peak events. Keep latency low for checkout. p95 authorization latency ≤ 500ms at 200 rps. User submits card details and receives authorization result. Attacker replays stolen card numbers. The system SHALL authorize card payments with the acquiring bank. Valid card and funds POST /payments is called Response includes paymentId and status=authorized. The system SHALL allow refunds on captured payments. A captured payment exists POST /payments/{id}/refunds A refundId is returned and payment status reflects refund. p95 authorization latency SHALL be ≤ 500ms at 200 rps. All payment endpoints SHALL enforce TLS 1.2+. The system SHALL apply velocity checks and challenge flows when risk is high.

Create a payment and request authorization.

paymentId, status (authorized|declined|pending) 422 for validation, 502 for upstream decline.

Refund a captured payment.

refundId, status Emitted when a payment status changes. paymentId, status, updatedAt POST /payments with valid card 201 with status=authorized Ensure p95 latency meets target.