> ## Documentation Index > Fetch the complete documentation index at: https://waffo.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Checkout Page Lifecycle & Receipt > How the Waffo checkout page behaves across the order lifecycle: reopening links after payment, processing states, result-page redirects, merchant display name, logos, cross-currency amounts and returning-customer prefill. This page covers how the Waffo-hosted checkout page behaves before, during and after payment. For payment-method display order and grouping, see the cashier customization documentation. ## What happens if a customer reopens a checkout link after the order has ended? For an extended period after the order reaches a final state — a platform-configured number of days, counted from when the order completed — the link still resolves to the real result: * A successful order shows the **success page** — it will not be misreported as failed just because the order validity period has passed. * A failed order shows the **failure page**, with the relevant error code (for example, order expired). After that period, the link can no longer be queried and the dedicated expired-link page is shown instead. Orders that are still processing remain queryable for as long as they are in progress. ## The checkout page is stuck on "processing". Is the payment lost? Not necessarily. When the payment flow hits an error that cannot be resolved immediately, the checkout page stays on a processing view and displays the reason. Behind the scenes, Waffo keeps retrying the order automatically. As soon as a retry produces a result, the page advances on its own to the success or failure page — what the customer sees is driven entirely by the backend order state, so there is no need for the customer to resubmit. Rely on your payment notification or order inquiry for the final state. ## After payment, does the customer get redirected back to my site? That depends on what you passed at order creation: | Order creation | Result-page behavior | | - | - | | Redirect URL provided | After the customer confirms on the result page, they are redirected to your URL. | | No redirect URL | The result page shows a **Close** button; clicking it closes the checkout page. | ## Which merchant name is shown on the checkout page and receipt? The checkout page, payment instruction page and receipt only ever show the **Cashier Display Name**, an optional field you configure in the Merchant Portal. Your KYB-registered legal name (Merchant Name) is **never** displayed to customers. If you have not configured a Cashier Display Name, the merchant-name field in the page header is simply hidden — the registered company name is not used as a fallback there. One exception worth knowing: on pages that carry a Merchant-of-Record disclosure footnote, the footnote falls back to the registered legal name when no Cashier Display Name is set. If you do not want the registered name to appear anywhere, configure a Cashier Display Name. ## Can I show different logos for different product lines under one MID? Yes. You can upload multiple logos in the Merchant Portal (at MID or SubMID level); each logo gets a unique logo ID. When creating an order, pass the logo ID to control which logo that checkout session displays. Fallback rules: * If the parameter is omitted, or the ID is invalid or does not exist, the **default logo** is shown. * The first uploaded logo is automatically the default; you can switch the default to any other logo in the Portal. * With no logo uploaded at all, no merchant logo is displayed. ## How are amounts displayed for a cross-currency order? When the order currency differs from the customer's payment currency, the checkout page shows the customer payment amount prominently together with the conversion breakdown — original order amount, exchange rate and any tax. For card payments the breakdown appears once the exchange rate can be determined: if several payment currencies are possible, it is shown after the customer enters enough card details to resolve the rate. When the order currency and the payment currency are the same, there is no conversion, so no breakdown is shown. Advanced layout options (such as which currency is the primary display and independent font sizes) are enabled per merchant — contact your Waffo representative if you need them. ## Do returning customers have to fill in their details every time? No, two mechanisms reduce repeated typing: * **Saved information** — the first time a customer fills in the form, a "save your information" option is checked by default. If they keep it, their details are brought out automatically on their next purchase. * **Merchant-passed prefill** — fields you already supplied at order creation that are marked user-editable are prefilled into the checkout form, where the customer can review and change them before paying. ## Which page states does the checkout have? I need something to test against. The page is driven entirely by the order state, so during integration testing you are really watching the order move. These are the states a customer can be on: | Page state | What the customer sees | What it means | | - | - | - | | Payment-method selection | The list of payment methods, grouped and ranked | The order has not resolved to a method yet | | Payment form | Card fields, or the fields a method requires | A method is chosen and needs input | | Redirecting | A short interstitial with a **Pay** and a re-check action | The customer has to go out to the payment method | | Silent form post | The processing view | Waffo is posting to the payment method in a hidden frame; there is nothing for the customer to do | | Instruction | A QR code, a payment code, or bank details plus instructions | The customer pays elsewhere and Waffo waits | | Processing | A spinner with the reason, where there is one | Waiting on the payment method, or retrying | | Success | The result page, or an immediate redirect to your URL | The payment succeeded | | Failure | The failure page with the error code | The payment failed and is not retryable | | Expired link | "This link has expired" | The link no longer resolves to a live checkout | Two of these commonly surprise people during testing. The **silent form post** looks identical to processing and is supposed to — the frame is deliberately hidden. And **instruction** and **processing** are pending states in which the page polls the order and advances by itself, so a page that appears to sit still is usually working correctly. Subscription orders can additionally start on a mode-selection step before any of the above. ## After a failure, can the customer pick a different payment method on the same checkout? Yes, for failures that leave the order retryable. The page returns to the **payment-method selection** state and shows the reason for the failure as an error message, so the customer can choose another method and pay on the same order and the same link — no new order, no new link. For a failure that is final — a hard decline, an expired order, a link that no longer resolves — the page goes to the failure page instead, and the customer needs a new order from you. You cannot tell these apart from the order creation response, because whether the failure is retryable is a property of the failure. Your integration should not assume the first failure notification is the end of the order; see [Payment results](/docs/en/support/payment-results-faq). ## Can I skip the Waffo result page entirely and send the customer straight back to my site? Yes, but not through an order parameter. When the bypass is enabled for your account, a checkout that reaches success or failure redirects immediately to your `successRedirectUrl` or `failedRedirectUrl` without rendering the Waffo result page at all — the customer never sees an intermediate confirm step. Two conditions both have to hold, so plan for the fallback: * The bypass has to be enabled for your account. There is no `cashierAppearance` key and no create-order field for it — ask Waffo support to enable it. * The corresponding redirect URL has to be present on the order. Without it the Waffo result page is shown, bypass or not. The warning that applies to every redirect applies here too, and more sharply because there is no page in between: arriving on your URL is not proof of payment. Read the state from your notification or from `POST /api/v1/order/inquiry` before you fulfil. ## Is an expired link the same error as a link that has been altered? No, they are different, and the difference is visible to the customer: | What happened | What the customer sees | | - | - | | The link resolves, but the checkout behind it is no longer live — already paid, or the session has passed | The dedicated **"This link has expired"** screen, which says the payment has already been processed or the session expired | | The link cannot be read at all — a truncated URL, a mangled or edited identifier, a URL copied out of another order | A generic **"Something went wrong"** screen | Two things follow from this. If a customer reports the generic screen, suspect the link's integrity first — most often the URL was rewritten, truncated by a messaging client, or passed through something that dropped part of it; this is the same failure mode as rewriting URLs between your App and a WebView. And if you are seeing the expired screen on a link you believe is fresh, the order behind it has reached a final state — query the order rather than re-issuing the link. ## Is 3-D Secure done on the checkout, or is it another redirect? Both parts happen, and only one of them is visible: * The **device-data step** runs invisibly while the customer is still on the checkout, before the payment is submitted. Customers do not see it and there is nothing for you to integrate. * The **challenge**, where it is required, is presented by the card issuer. That is an additional step out to the issuer's authentication page, after which the customer comes back to the checkout and the flow continues. Whether a challenge happens at all is the issuer's decision on that transaction, so you cannot promise a customer a single-screen card payment. If you build your own card page with the Waffo front-end SDK you have some control over how the challenge is presented — see [Google Pay and SDK 3DS flow control](/docs/en/developer-docs/integration/elements/frontend-integration#3ds-flow-control). For what happens when a challenge times out, see [Payment timeouts and finality](/docs/en/support/payment-timeout-and-finality-faq#3ds-authentication-timed-out-can-i-retry-on-the-same-order). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.