Skip to main content
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. 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:

​
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: 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.

​
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. No, they are different, and the difference is visible to the customer: 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. For what happens when a challenge times out, see Payment timeouts and finality.