Release Checklist / Definition of Done
This is the final page of the Start Here path and of the acceptance-testing guide. A payment integration is done only when every control below passes against the actual release candidate — not a debug build, and not the SDK calls compiling in isolation.
SDK setup alone is not a completed payment integration.
Related docs
- Start of the path: Start Here: integrate AppInChina IAP
- Preflight and acceptance: Client Payment Preflight and Acceptance Testing
- Backend verification: Server Verification and Entitlements
- Android components: Payments SDK Integration Guide for Android
Definition of Done
| # | Control | Required proof / acceptance condition | Owner |
|---|---|---|---|
| 1 | Products and identity | Each test product is configured; the app requires a valid authenticated account; customerIdentity and bizNo handling are implemented as documented. | Client technical lead |
| 2 | SDK and platform setup | Dependencies (including the pinned FastJSON 1.x version, no dynamic selector), callback receiver(s), client result Activity (where applicable), manifest declarations, and release-artifact configuration are present in the actual release candidate. initPayTools() is confirmed to succeed before WeChat Pay is offered. | Client mobile developer |
| 3 | Payment initiation | The release candidate can initiate each offered payment method and creates a diagnosable order/attempt. | Client mobile developer |
| 4 | Post-payment return | The app returns without crash and executes the intended result/callback flow, then requests fresh entitlement state. Tested for paid, cancelled, failed, and app-resume/relaunch outcomes, with entitlement state read from the client backend — never inferred from the Activity launch or callback arrival. For WeChat, the full WXPayEntryActivity → backend verification → entitlement route is validated with a real payment. | Client mobile developer |
| 5 | Backend verification | The client backend verifies transaction state through the canonical documented interface and handles repeat/retry safely. | Client backend developer |
| 6 | Entitlement | A verified paid order grants exactly the intended access; an interrupted/repeated attempt does not create duplicate access. | Client backend / product owner |
| 7 | Restore behavior | Access is refreshed correctly after relaunch, login, account switch, and reinstall/restore if relevant to the app. | Client QA |
| 8 | History and refunds | Purchase history is implemented if in scope; bizNo/support correlation works; refund reconciliation behavior follows the documented limitation and product policy. | Client backend / product owner |
| 9 | Wallet preflight | One named tester per wallet completes the low-value release-candidate in-app preflight, or provides a complete, triage-ready failure package. | Client tester |
| 10 | AppInChina acceptance | Client submits the exact release candidate, test credentials/context, and preflight result. Final acceptance is completed per the agreed test matrix. | Client + AppInChina Ops |
Sign-off
Each control should be signed off in your live documentation/issue system before the release candidate is submitted for AppInChina acceptance. Keep the sign-off record with the build's audit trail.