Test your integration
Test the behavior of your application, not just whether the SDK opens. Start with local fixtures for every status, then run approved end-to-end verification for each payment entry and native release build you intend to support. Requests in these guides target production; coordinate live verification with NextAppMarket.
Checkout and SDK launch
| Test | Expected result |
|---|---|
| Client changes the price or another user's order ID | Backend calculates the price and rejects unauthorized access. |
| Customer taps Pay twice; two backend workers receive the request | Both use the same durable attempt and command identity. |
| App is restarted after order creation | Saved business order resumes; a new charge is not created automatically. |
| Create request times out after the server accepted it | Exact lookup or same-key replay recovers the original order. |
| Invocation is null, expired, or has an unexpected kind | UI preserves the order and uses a recovery/error path. |
| Provider app is absent or launch is rejected | App gives useful feedback and checks the existing order. |
| WeChat/Alipay native payment | Test release package identity, callback routing, foreground resume, and cold start on real devices. |
| QR payment | A second device can scan; the original screen updates without a return callback. |
| Browser payment | Approved domains, referrer behavior where required, return navigation, and manual return all work. |
For Alipay QR, test the QR code generated from the cashier redirect_url. For WeChat QR, test the provider qr_url. The payloads and client handlers are different.
Confirmation and delivery
| Test | Expected result |
|---|---|
| SDK reports success before the platform order becomes paid | App shows checking/pending; delivery waits for confirmed payment. |
| Customer cancels, but a payment result remains unresolved | Backend queries the original order and does not immediately start another charge. |
| Customer pays and never returns to the app | Verified webhook or reconciliation worker completes fulfillment. |
| Webhook arrives before the create response is saved | Event is retained and retried after mapping recovery. |
| Webhook is duplicated, delayed, or out of order | State does not regress and the product is delivered once. |
| Webhook signature is invalid | Request is rejected without changing business state. |
| Backend stops after recording payment but before delivery | Durable fulfillment/outbox processing completes delivery on restart. |
| Two payment attempts unexpectedly become paid for one purchase | Both payments are recorded; purchase is delivered once and the duplicate is reviewed. |
| User opens a refunded order | Entitlement handling respects refund records; historical paid status does not regrant it. |
Use the signed webhook fixture and verifier to test authentication without a live charge.
Refunds and closing orders
Test a full refund, two permitted partial refunds, an excessive amount, concurrent refund requests, VERSION_CONFLICT, a lost submit response, review delays, unknown execution, and final success/failure events. Confirm that a successful HTTP response never displays Refund complete prematurely.
Test closing an unpaid order while the customer is completing payment. Follow the returned operation and query the order; handle the actual financial result before offering a replacement attempt.
Huawei-specific checks
Validate the agreed evidence encoder against the activated adapter. Test duplicate evidence, account ownership, interrupted purchase recovery, restoration after reinstall, and product type mapping. Stop the server between durable fulfillment and attestation, then confirm that the attestation is retried without delivering again. Verify which component owns provider consumption.
Ready to launch
You should be able to trace a customer purchase through business order, payment attempt, platform order, verified event or query, fulfillment, and refund. Support logs should include these identifiers and request IDs without storing credentials or full signed payment instructions.
Document your selected SDK versions, devices and browsers tested, activated entries, approved return destinations, and reconciliation/support owner. Local schema and fixture checks validate examples; they do not replace an activated provider transaction on a real device.