Gateway Selection
Part of Checkout technology for Australian merchants
Mapping payment steps before selecting a checkout tool
Map payment attempts, provider outcomes, retries and order-state changes before selecting a checkout integration.
Map store, buyer and payment-provider events before you choose a checkout tool. Show who starts a payment attempt, where the buyer may leave the site, how the provider reports an outcome and when the order changes state; that reveals handoff needs a screenshot cannot show.
Keep orders and payment attempts separate
Start with an order reference, amount and currency. Show the store creating a payment request, the buyer acting where required and the provider reporting an outcome. A retry may create another payment attempt for the same order. Record the provider reference for each attempt so staff can trace it.
- The store confirms the basket and amount to be charged.
- The store creates a payment request linked to its order reference.
- The buyer completes, cancels or leaves the payment step.
- The store obtains the current result, and receives a server notification if that integration provides one.
- The store checks the provider outcome and updates the order accordingly.
- Pending payments and later capture, if supported and needed, receive their own steps.
Messages depend on the provider and method. In Adyen’s documented Hosted Checkout flow, the buyer returns to the merchant site and a separate webhook reports the payment outcome. Map the events the chosen integration actually supplies.
Assign a response to each outcome
| Outcome or event | Store response to specify |
|---|---|
| Payment succeeds | Link the provider reference to the order and apply the store’s fulfilment policy. |
| Payment fails or is cancelled | Keep the order unpaid and offer an appropriate next step. |
| Payment remains pending | Explain that payment is still processing; do not show it as complete. |
| Session expires | Offer a new attempt where supported without duplicating the order. |
| Notification is repeated or delayed | Check it against the existing attempt before changing the order again. |
A browser return should not be the sole fulfilment trigger when the provider supplies a separate authoritative outcome. If the integration uses webhooks, verify their authenticity and establish how duplicate or out-of-order events are handled before applying order changes.
Add capture only when needed
Some payment methods and configurations allow authorisation and capture to be separate. If the business captures later, map the authorised state, capture request and capture result. In Adyen’s documented manual-capture flow, capture is a separate request after authorisation; map the request and reported result.
If the tool captures automatically, map that path instead.
Ask each candidate to show success, failure, a pending state where supported, and a retry using its permitted test method. Compare the provider event, store order status and customer message at each step, and record paths that cannot be demonstrated. Payout and bank matching belong in a separate reconciliation process.
