Hosted checkout launch tests beyond the successful payment

Define the expected order states

Start by writing the states your business understands, such as awaiting payment, confirmed, unresolved and cancelled. Map them to the documented transaction states exposed by the integration. Avoid using a single paid flag to represent every intermediate condition. Decide which verified event permits fulfilment and which conditions require investigation. For a physical order, releasing the warehouse task is a separate business action from displaying a successful browser screen. The test plan should say which system makes that decision and what evidence it uses when the customer's browser is absent.

Hosted checkout

Test the page the customer actually sees

Use representative order amounts and currencies to inspect the hosted journey. Check business identity, order context, visible methods and the return destination. Confirm that the methods shown are eligible for the account and configuration rather than assuming a provider's full product catalogue is available. Test on the device types customers use, including a small screen and a return from authentication. Keep card entry within the supported PSP-hosted interface. Do not add a custom collection field for sensitive card information merely to make a test or customer-support process easier.

Developer tools

Follow a successful payment through every system

Complete a supported test payment and trace its identifiers from the order to the transaction and notification. Confirm that the order updates once, that fulfilment runs once and that the operational record remains searchable. Stripe's checkout documentation and fulfilment guidance illustrate why server-side confirmation matters. A customer return page is useful feedback, but it must not be the only route through which the business learns the payment result. Test the same success while deliberately closing the browser before the return, then check whether the order still reaches the correct state.

Exercise abandonment and uncertain outcomes

Cancel the journey, leave the checkout open and interrupt the network where your test environment permits. Define what the customer sees when they return later. An abandoned browser session does not necessarily establish a final transaction failure, so the application should inspect supported status before offering another attempt. Include an API timeout and delayed notification in the plan. Each scenario needs an expected state and owner. The purpose is to expose ambiguity before launch, not to create a long spreadsheet of cases whose outcomes nobody has agreed.

• Test a successful payment without a browser return.
• Test repeated clicks and a repeated notification.
• Test a cancelled or abandoned customer journey.
• Test an unresolved response and subsequent recovery.

Test operational access and communication

Ask a colleague outside the implementation team to investigate one successful and one unresolved transaction. They should find the order reference, relevant provider connection and current verified state with their permitted access. Check that customer messages do not promise success before confirmation or expose technical secrets. Agree where support escalates a genuine mismatch. A technically correct integration can still fail operationally if only its author knows which dashboard or identifier to use. Keep the investigation steps with the release checklist and update them when the integration changes.

Release only the confirmed supported scope

OrsunPay hosted checkout presents methods available for the configured provider accounts and connects the buyer to the selected PSP. Available methods depend on provider, account, currency and configuration. The merchant retains its provider agreements and settlement arrangements. Confirm the checkout languages required for the rollout rather than assuming that the marketing website's language coverage applies to the payment interface. Release a defined scope, monitor its verified outcomes and retain a rollback plan for new orders. Treat additional methods, languages or provider capabilities as separate changes requiring their own acceptance checks.

Sources

• Stripe — Checkout
• Stripe — Fulfillment