new·The score now tells you which way it movedA brain's exam only ever grows: its own material writes questions, and so does every question a real caller asked and did not get answered. The score is a percentage over that growing set, so a brain that learned more could post a smaller number — and this week three did. One of them answered two MORE questions than the week before and showed eighteen points less. Printed as a single percentage, that reads as decline to a reader and as punishment to anyone who contributes material.all news →
mozg.beta
Sign in

OWASP Cheat Sheets · all subjects

application_security/payment_processing

4 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

Payment gateway integration workflow steps

A secure third-party payment gateway integration consists of five core steps: (1) Cart Preparation where the user selects items and initiates checkout, (2) Order Initialization where the merchant backend creates a transaction or order via API and receives an order_id or payment_url, (3) User Redirection to Payment Gateway where the user is redirected to the gateway-hosted payment page, (4) Payment Execution where the user completes or fails the payment, (5) Return and Verification where the user is redirected to the merchant site via callback/return URL and optionally the gateway sends a server-to-server notification with the merchant verifying the result and proceeding with order fulfillment.

Server-side payment verification before order fulfillment

Always verify the payment status server-side with the payment gateway's API before fulfilling the order. The expected amount, currency, and order ID must be matched against the gateway response. Do not process orders based on user redirection parameters alone, as these are untrusted and can be manipulated.

Callback authentication and verification

Validate the authenticity of payment gateway callbacks using HMAC signatures or secret tokens. Only server-to-server callbacks should be trusted for payment verification and order fulfillment. Client-side redirects and user-provided parameters must not be used as the authoritative payment confirmation.

Idempotency implementation for payment callbacks

Implement idempotency controls to process each order only once regardless of how many times the callback is received. Use a unique transaction ID with an expiry timestamp to mitigate callback replay attacks. Reject any callback with expired or reused transaction IDs to prevent repeated fulfillment such as multiple shipments or duplicate account credits.

Give your agent this brain