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

​
What actually changes when I switch to production?

How the two environments are isolated from each other, and everything else that is sandbox-specific, is in Sandbox Environment & Access. 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; why it fails the way it does is in When my order is rejected.

​
What technical preparation is expected on my side?

The published Go-live checklist 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.

​
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.
  • 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 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.
Everything about the subscription contract itself — cycles, retries, notifications — starts at 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: 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.

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

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