Going Live: The Real-World Process

Table of Contents

1. Why this is a business process, not just a config change
2. The six steps, in order
3. What this course doesn't cover yet
4. Beginner Pitfalls

---

1. Why this is a business process, not just a config change

Everything in Parts 1–6 gets you a working sandbox integration you can build and test on your own. Going live is not just a technical step — swap sandbox URLs and keys for production ones — it's also a business process involving ABA PayWay directly. None of what follows is documented on PayWay's public developer site; it's the practical, business-side process layered on top of the technical integration this course covers, based on real integration experience.

2. The six steps, in order

1. A contract comes first. Someone with authority on your side (e.g. your company's CEO/founder) needs to formally engage and sign an agreement with ABA PayWay before production access is granted. Registering a sandbox account (Part 1) is enough to start building and testing — it is not enough to go live.
2. You'll be added to a dedicated Telegram group with ABA PayWay's integration team once the contract is in place. This is their primary support/coordination channel during integration — expect to ask implementation questions there.
3. They'll provide reference documentation and a Figma design file. Production integrations aren't just "call the API correctly" — ABA PayWay also expects your checkout UI to follow their provided design (branding, layout, required elements), not the custom UI this course used for its sandbox example (which is fine for personal/learning projects, but not for production).
4. You implement to match both the API and the provided UI design, then submit your finished integration back to ABA PayWay for review.
5. They review and approve before you can launch. Don't assume "it works in my testing" is sufficient — production launch is gated on their sign-off.
6. Ask them for a sandbox simulator app. The real ABA Mobile app generally won't complete payments against sandbox QR codes or transactions. Ask your ABA PayWay contact (e.g. in the Telegram group from Step 2) for a simulator/test app that can scan sandbox QR codes — this is how you actually exercise the full flow end-to-end, including callbacks, before going live, rather than only ever seeing code: "00" at the request-creation step like this course's example does.

3. What this course doesn't cover yet

A few production-facing topics are genuinely out of scope for what's been built and verified so far, and are worth naming rather than glossing over:

• The required legal pages production checkout typically needs (Terms & Conditions, Refund Policy) — content and placement requirements should come from ABA PayWay directly during the review process in Section 2.
• Merchant Portal setup itself — this course's example only ever touches the API and sandbox credentials, never the portal UI.
• A concrete go-live checklist beyond the six steps above — the exact gating criteria are ABA PayWay's to define, not something to guess at here.

4. Beginner Pitfalls

• Don't wait until your integration is "done" to start Step 1. The contract and Telegram-group process in Steps 1–2 can take real calendar time — start it in parallel with development, not after.
• Don't design your own checkout UI for a production integration and expect it to pass review — Step 3's provided design isn't optional guidance, it's a requirement.
• Don't rely on the real ABA Mobile app to test a sandbox integration end-to-end. It generally can't complete sandbox payments — ask for the simulator app in Step 6 instead.