Use a hosted checkout page
Integrate a generated checkout destination and verify results without trusting the redirect.
Understand the redirect flow
Hosted Checkout, also called Collect Checkout in NMI’s guide, moves the customer from your payment trigger to an NMI-hosted payment page. The hosted page shows the configured products and amount, collects the payment details, and can return the customer to your site. This suits a workflow where a hosted redirect is acceptable and deep inline customization is unnecessary. online
Obtain the actual checkout configuration
Use the merchant’s configured hosted checkout destination. The current high-level guide contains an illustrative URL rather than a session-creation API contract. Do not construct a guessed Betterpay or NMI checkout endpoint. Confirm the merchant configuration, amount/product behavior, accepted methods and return destination before adding a button. Confirm Hosted Checkout availability for the merchant. Obtain the actual generated checkout URL or integration configuration through the authorized merchant setup. Review the configured item descriptions, amounts and payment methods. Configure and test the return experience for completion, cancellation and abandonment.
Add the payment trigger
An ordinary link is sufficient once a verified destination exists. The following application-owned helper intentionally accepts only a preconfigured URL; it does not manufacture a checkout session. A server-managed allowlist should control that configuration. Never accept an arbitrary redirect destination from a query parameter. export function setCheckoutLink(anchor, configuredCheckoutUrl) { const destination = new URL(configuredCheckoutUrl); if (destination.protocol !== 'https:') throw new Error('HTTPS required'); anchor.href = destination.href; anchor.textContent = 'Continue to secure checkout'; } // Supply the merchant's verified generated URL from trusted configuration.
Verify the order after return
A customer can edit URL parameters. A return value such as payment=success must never be the sole evidence used to mark an order paid or ship goods. Show a checking state, read your server-side payment record and reconcile with the gateway/reporting path configured for this checkout. If the result is not confirmed, retain a pending state. Customer behavior Required application response Returns after payment Look up verified server-side order state Closes the hosted tab Keep order pending until reconciled or expired Edits return parameters No change to authoritative payment state Clicks checkout again Check existing order/payment state before another attempt
When to choose the embedded route
If you need dynamic order pricing, detailed in-product state handling or a thoroughly specified server request, use Payment Component plus REST. Hosted configuration and the return-to-order correlation mechanism must be confirmed for the actual merchant setup. This guide deliberately does not claim an undocumented hosted-session API exists.