Invoice Redirect
Pronunciation: IN-voys ree-dur-EHKT
Definition
Invoice redirect is the navigation of a payer between a merchant site, hosted invoice, payment provider, wallet, authentication page, or post-payment destination. Redirects preserve checkout continuity but are not trustworthy payment evidence. Every redirect URL and returned state should be validated, and the merchant should rely on backend payment confirmation before completing the invoice. Invoice Redirect systems should preserve the issued version, due balance, denomination, tax treatment, payment instructions, and every later adjustment or settlement event.
Overview
Invoice redirect is the navigation of a payer between a merchant site, hosted invoice, payment provider, wallet, authentication page, or post-payment destination. Redirects preserve checkout continuity but are not trustworthy payment evidence. Every redirect URL and returned state should be validated, and the merchant should rely on backend payment confirmation before completing the invoice. Within Invoice Redirect, and especially at the boundary with Hosted Invoice, implementations should preserve the issued version, due balance, denomination, tax treatment, payment instructions, and every later adjustment or settlement event.
A return URL can send the customer back after success, cancellation, or failure. The browser can arrive before the provider’s webhook or final blockchain confirmation.
The redirect should carry an opaque state value bound to the session, order, and expected provider. Sensitive invoice data should remain server-side.
Deep links to wallets and mobile applications need controlled schemes and universal-link configuration. The application should recover safely when the user returns through another device or browser.
Risks include open redirects, phishing, state replay, session swapping, leaking invoice identifiers, spoofed query parameters, and false success pages.
Systems should allowlist destinations, sign or bind state, use HTTPS, expire tokens, log transitions, verify origin where possible, and confirm payment server-side.
Implementations should link Invoice Redirect to Redirect Checkout and Hosted Invoice through auditable references. Although the records can share a customer or transaction, Invoice Redirect retains its own authority, lifecycle, and recovery rules.
For Invoice Redirect, version control is essential. When Invoice Redirect interacts with Redirect Checkout, corrections should use a replacement, credit note, cancellation, or auditable adjustment linked to the original record instead of overwriting historical values. In the relationship between Invoice Redirect and Hosted Invoice, exports and reports should reproduce the document as it existed at issuance, including the customer, tax rule, exchange-rate basis, payment terms, and payment instructions that were actually communicated.
Key Takeaway
Invoice redirects must use allowlisted destinations and bound state, while backend events, not browser parameters, determine payment success.
Sources
- Peppol BIS Billing 3.0 — OpenPeppol (2026-08-01)
- OxaPay API Reference: Generate Invoice — OxaPay (2026-08-01)