When a mobile payment outcome is uncertain, keep the order and payment attempt identifiable, verify the provider's state and avoid creating another charge blindly. Distinguish pending, failed, cancelled and confirmed outcomes. The app returning from a payment screen is not by itself proof that money moved or an order should be fulfilled.
Let’s plan your payment recovery flow.
Bring your workflow and the decisions you need to make. We’ll help you clarify requirements, review the trade-offs and define a practical next step.
Model order and payment states separately
An order can exist while its payment is unresolved. Give each a stable reference and define which provider evidence authorises fulfilment. A user-facing success animation should follow the agreed confirmation rule, not become the rule.
For a hypothetical booking app, retain the selected booking reference while checking a delayed payment. Explain whether the slot is held, released or subject to a defined expiry. Do not let the interface imply that payment uncertainty guarantees availability.
Specify the uncertain-outcome matrix
| Scenario | Expected product behaviour | Check before another action |
|---|---|---|
| Network drops after payment submission | Show checking or pending state | Provider and existing attempt reference |
| User closes the payment screen | Resume the same order status | Current payment outcome |
| App restarts | Recover active order context | Authorised server record |
| Callback arrives late | Apply a permitted state transition | Existing fulfilment and provider evidence |
| User taps Pay again | Prevent accidental duplicate action | Whether a new attempt is actually allowed |
| Payment succeeds after order expiry | Route the exception visibly | Business treatment agreed with the owner |
The final row needs an explicit operating process. A late success may require review; the software should not invent a cancellation, refund or new booking policy.
Use the server as the decision boundary
Check provider documentation for supported status queries, event verification and idempotency. Do not rely on an unverified client parameter as evidence of payment. Keep credentials and provider secrets outside the mobile application.
Handle repeated callbacks and retries without repeating fulfilment. The webhook reliability guide covers delivery failures, while this acceptance matrix focuses on the user's interrupted mobile journey.
Give support a traceable record
Show a useful reference and the last confirmed status. Support should be able to investigate the same order and payment attempt without asking the user to repeat the transaction to diagnose it.
Test provider-supported sandbox scenarios and controlled interruptions. Clearly distinguish simulated outcomes from actual live transactions; do not use real customer money as a routine acceptance fixture.
Payment-state questions
Should pending become failed after a timer expires?
Not without a provider-aware rule. A local wait limit does not establish that the external payment failed.
Is retrying the checkout always safe?
Only after checking the existing outcome and applying the integration's duplicate-protection rules.
Include these cases in mobile integration testing, and review the order lifecycle with Drema's app developers.
