Redirect checkout
Create a session, send the customer to a controlled payment page, and return them to a status view.
Good for: focused implementationIntegration routes
Connect at the right depth
Start with the lightest path that returns a reliable payment state. Add server control when your operation needs deeper order, refund, and reconciliation logic.
Apply for merchant accessThree paths
From hosted flow to server control
Availability, API key, project ID, endpoints, signed postbacks, and production approval are confirmed for the merchant.
Referenced collection
Create an approved payment link, retain the merchant reference, and verify the final result on the backend.
Good for: remote ordersServer integration
Create sessions from your backend, verify status, and validate signed asynchronous postbacks.
Good for: custom operationsTechnical architecture
One gateway route, explicit outcomes
The diagram is a conceptual implementation map. It does not imply a particular bank, payment method, certification, or provider relationship.
- Create a merchant reference before payment.
- Handle pending as a real state.
- Verify the outcome on the server.
- Keep the settlement record connected.
Go live checklist
Test the outcomes, not only the happy path
A production ready integration knows what to do when the payment is delayed, repeated, reversed, or incomplete.
Successful payment
Verify the server result, update the order once, and show the customer a useful confirmation.
Pending result
Keep the order in a non-final state and process the later verified event.
Failure and retry
Give the customer a safe retry path without duplicating the order.
Refund
Attach the reversal to the original transaction and update the merchant record.
Duplicate event
Make event handling idempotent so a repeated notification does not repeat fulfilment.