Hosted checkout or a custom integration?

1. Separate the main integration approaches

A hosted payment page takes the customer to a page supplied by the payment provider. A prebuilt embedded form stays within your website. An interface assembled from individual components gives your team more control over the page it builds.

Stripe documents these approaches as a hosted page, embedded form and a checkout built with components. That is a product example: check the features and integration options available from the provider you are considering.

Do not confuse the interface approach with the choice of payment methods. A hosted page can offer several methods, while a custom interface can still be constrained by the selected provider’s capabilities. Assess the interface, payment processing and order connection as related but distinct parts of the decision.

Ask to see your actual journey from basket to payment and back to the store’s order confirmation. If extra information is needed, establish where it is collected and validated. Check the handoff between pages, understandable ways back and what happens to the basket when a customer stops midway.

2. Define requirements before design preferences

Which payment methods, countries, currencies and recurring payment flows do you need? Include discounts, delivery options and the connection to your store platform. The right-looking interface is of limited use if a required workflow is missing.

Separate essential capabilities from design preferences. Decide what the team can build and maintain. An existing store plugin may be a better fit than a new custom connection if it reliably covers the required process.

List the purchase flows you cannot do without. These might include a one-off purchase, a later order adjustment or a recurring offering. Record whether each requirement belongs to the store, an extension or the payment provider. A product name alone is not adequate confirmation of a particular capability.

Confirm the conditions for your required methods and markets directly with the provider. Distinguish between a technically supported method, one enabled for your merchant account and one displayed in a particular transaction. Use agreed realistic scenarios for acceptance rather than watching only a prepared standard payment.

3. Compare the operating workload

Look beyond the initial integration. Payment method changes, mobile usability, error messages, testing and upgrades all create ongoing work. Establish which parts the provider maintains and which remain with your team.

Greater design control does not by itself establish better sales results. Assess specific usability problems and the evidence available to you. General conversion claims are not a sufficient reason to take on more development.

For each approach, identify changes your team will need to make itself. These can include field arrangement, error presentation, translations and updates. Ask which changes are configurable and which need development work or an upgrade to the store extension.

Include diagnosis and support. Can the team match a failed attempt across the store and payment platform? What can customer service see without unnecessarily spreading payment information? Assign ownership of investigating a blocked purchase and approving changes to the customer-facing interface.

• Test the available customisation against a real purchase journey.
• Separate implementation costs from ongoing maintenance.
• Assign responsibility for the store, payment connection and support.

4. Connect payment confirmation to order processing

A customer reaching the success page is not a sufficient foundation for reliable order release. The browser can close or the return journey can fail. The confirmed payment status still needs to reach the system responsible for the order.

Stripe documents server-side events for this purpose and accounts for payments confirmed later. Plan equivalent status handling for your provider and include delayed or repeated notifications in the tests.

Describe state transitions explicitly. Creating a payment attempt is not the same as confirming payment. Agree when the order is reserved, released for processing or closed again. If confirmation comes later, the process must still work when the customer is no longer on your website.

Make the connection between payment and order traceable through a unique reference. A repeated confirmation must not create a second dispatch release. A missing notification needs an agreed investigation and reconciliation process. The actual event handling must follow the chosen provider’s documentation and state model.

5. Test interruptions, delays and refunds

Run successful and declined payments, an abandoned payment step and a confirmation that arrives later. Check the resulting order status and downstream handling in each case.

Include full and partial refunds where the business requires them. Decide who initiates a refund and how the outcome remains traceable across the store, payment platform and accounting process.

Review error messages from the customer’s perspective. Is it clear whether to retry, choose another method or contact support? Retaining appropriate form and basket information can make re-entry easier. Do not assume the same payment attempt can simply be repeated indefinitely; confirm the intended retry behaviour with the implementation team.

For refunds, seeing an available button is not enough. Follow the operation from initiation to confirmation in the connected systems. For partial amounts, check how previous refunds are accounted for and how support recognises the current position. Agree what should happen if the refund process is interrupted or returns an error.

6. Record why the chosen approach fits

Use a short decision record covering mandatory features, gaps, implementation effort, maintenance and acceptance cases. Mark the assumptions that still need confirmation from the provider.

Questions about payment data handling and contractual responsibilities require a specific review with the provider and relevant advisers where needed. The choice of embedding method alone does not settle those requirements.

Only use weighted scoring if it keeps the decision understandable. A missing mandatory capability should not be cancelled out by a long list of minor design benefits. Start by separating exclusion criteria from points on which a deliberate compromise is possible.

Record the choice so it can be reviewed later: selected approach, verified capabilities, remaining conditions and accepted limitations. Name a reason to reassess it, such as an additional market or new recurring purchase flow. Changing approach later is still an integration project and should not be assumed to be effortless.