> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rc.cleverhub.co/llms.txt
> Use this file to discover all available pages before exploring further.

# Multi-Currency Hosted Checkout

> What your customers see on Hello Clever's hosted checkout page for multi-currency payments: card, bank transfer, QR, and mobile money flows, the instructions panel, and the I have paid step.

When you collect a payment through the [Multi-Currency Gateway (v3)](/api/v3/introduction) or a payment link, your customer completes it on a Hello Clever hosted checkout page rather than in your own checkout UI. This page describes what they see there, so you know what to expect and what to tell them if they get stuck.

<Note>
  This is a different surface from the Hello Clever app checkout covered in the [regular](/platform-overview/customer-guides/regular-checkout) and [express](/platform-overview/customer-guides/express-checkout) checkout guides. Those cover AUD payments with cashback through the Hello Clever app; this page covers the multi-currency hosted page.
</Note>

## The page your customer lands on

Every hosted checkout page carries the same frame, whatever the payment method:

* **Your name and logo** at the top left, so the customer can see who they are paying.
* **A language switcher** at the top right, offering the languages relevant to the currency (for example, English and 繁體中文 for HKD, English and Swahili for KES, English and Setswana for BWP), plus a translate control.
* **Continue on your phone**: moves the payment to the customer's mobile device, which matters for QR codes and mobile money prompts that need a banking or wallet app.
* **The amount**, displayed prominently in the payment currency.

Depending on the method, the page then shows either a form to fill in, or a set of payment instructions to act on.

## Form-based methods (card and bank details)

Card payments and methods that need customer identification show a form. Typical fields are first and last name, email, phone number with a country dial code preselected for the currency, and billing address, city, state, postal code, and country. Some methods also ask for a customer type (individual or organisation), an account number, or a date of birth.

The customer completes the form and selects **Next** to continue to payment.

### Address autocomplete

For methods that require an address, the address field suggests matching addresses as the customer types and validates the result. The customer picks their address from the dropdown rather than typing it out in full, which cuts down on typing errors and on payments failing verification.

<Tip>
  If you pre-fill customer details when you create the payment, those values are carried into the form, and the customer only has to fill in what is missing.
</Tip>

## Instruction-based methods (bank transfer, QR, and mobile money)

Bank transfer, QR, and mobile money methods do not take payment on the page. Instead they display what the customer needs in order to pay from their own bank or wallet, together with:

* **The amount**, with a **Copy** button.
* **Expiry**: the time by which the payment must be completed.
* **Transaction ID**: the reference for the payment, useful if the customer needs support.
* **I have paid**: the button the customer selects once they have sent the payment.
* **See Instructions**: opens fuller instructions for that method.

What sits above those depends on the method:

<Tabs>
  <Tab title="Bank transfer (PayID)">
    The page shows the **PayID** to pay to, with a **Copy** button, and the exact amount to send, also copyable.

    Directly beneath the amount is an alert reminding the customer to enter the amount accurately so the payment can be processed without delays.

    <Warning>
      The amount must match. Because a bank transfer is initiated in the customer's own banking app, nothing stops them sending a different figure, and an underpayment or overpayment has to be reconciled manually. This is why the alert sits immediately below the amount field rather than off to the side.
    </Warning>
  </Tab>

  <Tab title="QR code">
    The page shows a QR code for the customer to scan with their banking or wallet app, alongside the amount and expiry. The customer scans, pays in their app, then returns and selects **I have paid**.

    Most QR schemes expire well before the page does, so the customer should complete the payment promptly rather than leaving the page open.
  </Tab>

  <Tab title="Mobile money">
    The page confirms that the customer will receive a **PIN prompt on their phone number**, shows that number back to them, and shows the amount to approve.

    The customer approves the prompt on their handset, then selects **I have paid**. See [mobile money payments](/api/v3/introduction#mobile-money-payments) for the network-specific requirements.
  </Tab>
</Tabs>

## The Attention panel

Instruction-based methods carry an **ATTENTION** panel beside the payment details, styled in blue with a matching information icon. It lists the conditions that decide whether the payment succeeds, and its content is specific to the method and country, covering which networks are supported, how quickly the customer must respond to a prompt, whether they need to keep the page open, and how long processing can take.

Common points across methods include:

* Respond promptly to any OTP, PIN, or push prompt; a slow response causes the payment to time out.
* Make sure the wallet or account has sufficient balance before starting.
* Do not close or refresh the page until the payment is complete and **I have paid** has been selected.
* Some methods can take up to 24 hours to reflect, depending on the bank or wallet.
* If the amount or details are incorrect, the transaction may not be recognised.

<Note>
  Read the Attention panel for the methods you enable and reflect the same points in your own order-confirmation messaging. Most failed instruction-based payments come from a customer ignoring a prompt or closing the page early, both of which the panel warns against.
</Note>

## After the payment

Once the customer selects **I have paid**, Hello Clever confirms the payment against the payment rail and sends the customer to your success or failure page if you configured redirect URLs.

<Warning>
  **I have paid** is the customer telling you they have paid, not proof that they have. Selecting it does not settle funds. Confirm every payment against the webhook, which is the source of truth. See [handling webhooks](/api/v3/introduction#step-by-step-integration-guide).
</Warning>

<Tip>
  In sandbox, **I have paid** opens the payment simulator instead, so you can walk through the success and failure paths without moving real money.
</Tip>


## Related topics

- [Payment Gateway 3 API (v3)](/api/v3/introduction.md)
- [Hello Clever API Overview](/api/overview.md)
- [Industry Use Cases](/getting-started/industry-use-cases.md)