Online checkout
Connect your order to the checkout page provided through your merchant account service. Verify the payment result, update the order once and recover any interrupted attempt.
DevelopersBefore you begin
- The checkout connection and instructions assigned to your merchant account
- Your order, amount, currency and references for each payment attempt
- The payment methods and capture policy confirmed for your setup
- Instructions for verifying results and recovering transactions
On this page
The checkout flow
Your application keeps the order and its payable amount. The checkout page collects payment details and handles processing through the merchant account service. Use the verified payment record to decide how the order should proceed.
- Your orderMerchant account servicePrepare checkout
Keep the order, amount, currency and payment attempt together.
- Merchant account serviceCustomer checkoutPresent the checkout page
Present the purchase and methods configured for the merchant account.
- Customer checkoutPayment processingProcess the payment
The customer submits payment through the configured checkout flow.
- Payment recordYour applicationVerify and match
Match the verified payment to its original order and attempt.
- Your applicationYour orderUpdate the order once
Record the confirmed result once. Investigate an unresolved attempt before retrying.
Confirm processing responsibilities
Agree which service submits the payment, how capture is handled and how your application verifies the result. Use one processing path so a repeated click, callback or notification cannot trigger another charge.
| Responsibility | Decision |
|---|---|
| Payment submission | Which service submits the payment, and when it is permitted to do so. |
| Authorization and capture | Whether capture follows authorization separately or is included in the configured sale flow. |
| Payment verification | How your application obtains and verifies the result for the original attempt. |
| Repeated interaction | How repeated clicks, reloads and notifications resolve to the existing attempt. |
Confirm who submits the payment, who controls capture and which record determines the order’s payment state.
Prepare the order and payment attempt
Load the order from your server
Confirm that the customer may pay this order and that the order remains payable. Read the merchant, amount and currency from your stored record, not from totals supplied by the browser.
Track the payment attempt
Keep a reference for each attempt to pay the order. Connect it to the order and merchant account, and check for an unresolved attempt when the customer refreshes or opens another tab.
Use the assigned checkout connection
Follow the setup instructions provided through your merchant account service. Keep account credentials on your server and use the environment provided for sandbox or production.
Authorization or sale?
Confirm whether the configured flow authorizes first or authorizes and captures together. Record the actual operation and follow the account’s capture policy; neither outcome confirms bank receipt.
What if the order changes?
Recalculate the payable total on your server and check the existing attempt before starting a new checkout. Do not associate an existing attempt with a different merchant, currency or order total.
Present the checkout page
Use the checkout presentation supported by your assigned connection. Collect payment details within that checkout and display purchase information consistent with the stored order.
Check the customer journey on desktop and mobile, including cancellation, return to the order and an interrupted connection.
Display and return behavior
Confirm the supported display options, website setup and return behavior with our integration team. Follow the supplied instructions rather than assuming an embedded form or a redirect is available.
Closing or reopening checkout
Closing the interface does not cancel a payment already submitted. Check the original attempt before opening another payment flow.
Wallets and bank payments
Use only the methods configured for the account. Confirm the domain, device and account requirements for wallets. ACH has its own authorization, completion and return process; do not apply card authorization or capture labels to it.
Verify and update the order
Obtain the payment result using the verification or lookup procedure assigned to your integration. A browser callback, redirect or successful HTTP response does not by itself establish that a payment was approved.
Verify the payment result
Use the verification and payment lookup instructions supplied by our integration team. Check the result for the original attempt. If it cannot be verified, keep it unresolved and follow the recovery procedure.
Match the payment to the attempt
Check the processing account, order or reference mapping, amount, currency, transaction ID and actual operation. Resolve any fields absent from the result through the authoritative payment record. Reject a mismatch instead of attaching the payment to another order.
Update the original order once
Save the verified transaction reference and result in an atomic update to the original attempt. Repeated callbacks and notifications must not create another charge or repeat fulfillment. Authorization, capture and fulfillment remain separate decisions.
| Outcome | Order handling |
|---|---|
| Authorization approved | Record the authorization reference. Follow the merchant’s capture and fulfillment policy; do not label the payment captured. |
| Capture accepted | Record the capture operation and its status. Settlement and bank receipt remain later events. |
| Payment declined | Leave the order unpaid. Offer another permitted attempt only after the decline is confirmed. |
| Pending or unknown | Keep the attempt unresolved and recover its status. Do not mark the order paid or automatically create another charge. |
Recover interrupted attempts
Treat an uncertain outcome differently from a confirmed decline. Start with the existing order, attempt and transaction references. Browser refresh, timeout and closing checkout are not evidence that processing stopped.
| Situation | Next action |
|---|---|
| Checkout cannot open | Check the assigned environment and configuration. Request the relevant error definitions if the cause is unclear. |
| Customer clicks or reloads again | Resolve the original attempt before permitting another payment. |
| Response is missing | Look up the original payment through the assigned recovery path; an immediate empty result is not proof of failure. |
| Payment is confirmed declined | Retain the declined attempt and follow the permitted retry process. |
| Payment is confirmed successful | Update the original order once and retain the verified transaction reference. |
The browser closes or the result never arrives
Recover through the assigned transaction lookup and verified payment events. If no transaction ID reached the browser, use the server’s stored attempt and supported reference mapping. No result found immediately is not proof of failure. Keep the attempt unresolved and escalate through support if the documented recovery path cannot establish its outcome.
Authentication is canceled or fails
Distinguish a confirmed authentication failure or cancellation from a communication failure. Preserve the original attempt, resolve any uncertain processing state and let the customer choose a permitted next action. Do not automatically resubmit the payment.
What to record for support
Record the environment, integration version, order and attempt references, available transaction ID, reported error and time. Share the original error information through the support channel without including payment credentials or tokens.
Prepare for launch
Run these checks with your assigned sandbox and configured payment methods. Keep the request references, payment result and order state together.
- A successful payment
- The verified merchant, amount, currency and operation match the order. The payment produces only the intended order update.
- An altered order or result
- A changed browser total, wrong account, modified result or reused result from another order is rejected.
- Refresh and concurrent tabs
- Both views resolve the same active attempt. A second submission cannot create a duplicate charge or fulfillment.
- An interrupted response
- Close the browser after submission or interrupt the connection. Recover the original result before offering another attempt.
- Declines and authentication
- Confirm the customer can recover from a decline or canceled authentication without an automatic retry.
- Checkout and device behavior
- Check opening, closing and returning to checkout, including partial loading and interrupted connections. Use enabled wallets on eligible devices and ACH separately where configured.