> ## 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.

# What Has to Happen Before I Can Take Live Payments?

> The whole path to production in one place: which stages gate live payments, what actually changes when you switch from the sandbox, what integration acceptance asks for and when you can use the shorter template, what technical preparation is on your side, and how adding a country or a payment method works once you are already live.

This page is the map. Each stage has a page of its own; what was missing was something that says
which stages exist, in what order, and which of them you drive yourself.

## Which stages gate live payments?

Four, and they are sequential — the Portal's Home page shows the first three as cards that unlock in
order:

| Stage | Who drives it | Where it is covered |
| - | - | - |
| 1. Account verification | You | [Self-Serve Sign-up, Sandbox & Account Verification](/docs/en/support/getting-started-self-serve-faq) |
| 2. Review of what you submitted | Waffo | Same page — including what a returned application means |
| 3. Payment enrollment — your payment methods being registered | Waffo, per payment method | [Payment Enrollment](/docs/en/support/payment-enrollment-faq) |
| 4. Integration acceptance | You, confirmed by Waffo | Published [Acceptance criteria](/docs/en/developer-docs/tools-and-references/references/acceptance-criteria) |

Two things follow from the ordering:

* **Payment enrollment cannot start before your review is approved.** The Home card stays locked and
  says so. Chasing enrollment while verification is outstanding does not move it.
* **Integration acceptance runs in the sandbox**, so you can do all of stage 4 while stage 3 is
  still in flight. You are not idle waiting.

Passing verification is not the same as being able to take payments — that distinction, and how to
read each payment method's enrollment state, is the first section of
[Payment Enrollment](/docs/en/support/payment-enrollment-faq).

## What actually changes when I switch to production?

| Thing | Sandbox | Production |
| - | - | - |
| API domain | The sandbox domain | The production domain |
| SDK environment | `Environment.SANDBOX` | `Environment.PRODUCTION` |
| API key | A sandbox key | A **separate** production key |
| Signing keys | A pre-generated pair, private half visible in the Portal | A pair **you** generate; the private half is never shown to you, and never sent to Waffo |
| Payment methods | Whatever your sandbox configuration enables | Whatever your payin agreements say — a different list |
| Limits and refund rules | Sandbox configuration | Your agreement values — read them fresh |
| Payment behaviour | Simulator buttons, no real channel | Real payment methods, real money |
| Merchant ID | Its own sandbox merchant ID | A different one — the Integration page names the one you are signed in to |

How the two environments are isolated from each other, and everything else that is sandbox-specific,
is in [Sandbox Environment & Access](/docs/en/support/sandbox-environment-and-access-faq).

The pairs to be deliberate about are the two key rows. **Do not carry sandbox credentials or a
sandbox key pair into production** — they are not interchangeable, and a key from the wrong
environment fails as an invalid key rather than as a permission problem. The full item-by-item
checklist, including the commands to generate a production key pair, is the published
[Go-live checklist](/docs/en/developer-docs/getting-started/go-live); why it fails the way it does is in
[When my order is rejected](/docs/en/support/order-rejection-self-diagnosis-faq).

## What technical preparation is expected on my side?

The published [Go-live checklist](/docs/en/developer-docs/getting-started/go-live) is the authority, and
it covers four things worth naming here so you can plan them into a sprint rather than discover them
on cutover day:

* **Timeouts** — a recommended call timeout, with a floor.
* **DNS** — a recommended TTL, and not pinning addresses.
* **Logging and alerting** — on order creation, order inquiry and webhook handling specifically,
  because those are the three places a go-live problem shows up first.
* **Where you deploy** — a recommendation about region and latency, with an extra step if you deploy
  in mainland China.

If you integrate inside an app, there is a fifth group about what your WebView must allow. Several
payment methods depend on launching an external app, downloading a QR image, or preserving query
parameters across a redirect — see the published
[Payment method integration notes](/docs/en/developer-docs/tools-and-references/references/payment-method-integration-notes).

## What does integration acceptance ask for?

You run a set of cases in the sandbox, record the results in a template, and submit the template to
your Waffo technical support group, which confirms it. What is checked: the payment success and
failure paths, webhook handling **and webhook idempotency**, refunds and subscriptions if you
integrated them, your handling of the exception scenarios, parameter quality, and whether you
persist the right identifiers.

Two practical points people miss:

* **Some cases are reproduced with reserved sandbox amounts.** They return the matching error on
  purpose. Use the published list rather than inventing amounts — see
  [Sandbox simulator](/docs/en/developer-docs/tools-and-references/developer-tools/sandbox-simulator).
* **You do not have to test every payment method.** Coverage is by representative: at least one
  card, at least one method per country per type, plus any method that needs a special parameter,
  and the wallet-native methods tested on a real device.

## I have integrated before and I am only adding one payment method. Do I repeat the whole thing?

No — there is a **shorter template for a subsequent one-time-payment integration**, and it exists for
exactly this case. Use it only if you have already passed acceptance at least once; a first
integration uses the full template.

It asks you to state the scope up front — your merchant ID, the contracted product, the payment
methods and the APIs this integration covers — and then to run the cases that are actually in
scope: order payment success and failure, payment notifications, cancellation, refunds and refund
notifications, with cancellation and refund only if this integration includes them. Both templates
and the selection rule are on the published
[Acceptance criteria](/docs/en/developer-docs/tools-and-references/references/acceptance-criteria) page.

## I already run one-time payments and now want subscriptions. Is that a second go-live?

Not a second account, but it is a second integration, and it has its own acceptance path: there is a
separate subscription acceptance template alongside the one-time-payment one, with its own cases —
first-period payment activating the subscription, a simulated renewal, and cancellation.

Two consequences:

* The two products are separate on your agreements, so a payment method contracted for one-time
  payments is not automatically contracted for subscriptions. Check the `Product` column on Service
  → Payin, and the product field in the payment-method configuration response.
* The sandbox lets you simulate renewals without waiting for a real billing cycle, which is how you
  run the renewal cases — see [Sandbox Testing](/docs/en/support/sandbox-testing-faq).

Everything about the subscription contract itself — cycles, retries, notifications — starts at
[Subscription FAQ](/docs/en/support/subscription-faq).

## What should I watch on the first day of live traffic?

Four things, and all four are readable by you without asking anyone:

| Watch | Where |
| - | - |
| Are webhooks reaching you, and being acknowledged? | The Portal's webhook log — see [Webhook Log](/docs/en/support/portal-webhook-log-faq) |
| Are orders being rejected, and on what? | The error code, then [When my order is rejected](/docs/en/support/order-rejection-self-diagnosis-faq) |
| Are payments failing after creation, and why? | The failure code and description on the transaction record — see [Transaction Field Reference](/docs/en/support/transaction-field-reference-faq) |
| Do your own alerts fire on order creation, inquiry and webhook handling? | Your side — this is the logging item on the published checklist |

The one habit worth forming on day one: **treat the webhook or an inquiry as the authority on a
payment result, never the customer's redirect back to your site.** Why, and what the redirect does
and does not prove, is in [Payment Results](/docs/en/support/payment-results-faq).

## Can I keep testing after I am live?

Yes. The sandbox does not go away, and it remains the place to reproduce a problem without moving
real money. Keep the two sets of credentials clearly separated in your configuration — the fastest
self-check on which environment a credential belongs to is in
[What can I change myself?](/docs/en/support/self-service-boundaries-faq).

## Once I am live, how do I add a country or a payment method?

The mechanism is the same one that got you your first methods: an agreement row is created on
Waffo's side, and it then appears on **Service → Payin** and in the payment-method configuration
response. You do not reconfigure anything and there is no downtime — existing rows are untouched, and
whether your integration has to change at all depends on whether you name payment methods
explicitly. That, and the country-versus-region question, are in
[Currency & Method Enablement](/docs/en/support/currency-and-method-enablement-faq).

Where a new method needs its own registration, its state is visible per method in the payment
enrollment detail — the same view you used before your first go-live.

## Where do I look next?

| Question | Page |
| - | - |
| The item-by-item pre-production checklist | Published [Go-live checklist](/docs/en/developer-docs/getting-started/go-live) |
| What each stage of the sign-up path asks for | [Self-Serve Sign-up, Sandbox & Account Verification](/docs/en/support/getting-started-self-serve-faq) |
| What my payment methods' enrollment states mean | [Payment Enrollment](/docs/en/support/payment-enrollment-faq) |
| What I am contracted for, with limits and refund rules | [Payin Agreements & Transaction Limits](/docs/en/support/payin-agreements-and-limits-faq) |
| Which settings are mine to change | [What can I change myself?](/docs/en/support/self-service-boundaries-faq) |
| How to test each scenario in the sandbox | [Sandbox Testing](/docs/en/support/sandbox-testing-faq) |


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.