A customer leaves your app to authenticate a payment, then returns to an unchanged basket. Should they press Pay again? That moment deserves a place in the development brief: customer money and an actual booking depend on it, while an attractive screen may provide too little information for a decision.
To buy a clear implementation, request failure, waiting and return scenarios rather than one successful demonstration. Customers and staff should know what is established and what remains unknown. The same state should be available when opening the order from another device, independently of the phone's memory.
Start with one order timeline
Imagine an app booking a physical home-maintenance visit, rather than purchasing digital content. This illustration involved no actual collection. A customer selects an appointment, starts a payment attempt and leaves during authentication. Track the order reference, attempt reference, provider outcome, server knowledge and customer display.
Record the information source and time beside each point. “A success symbol appeared” describes an interface, without explaining why the appointment became confirmed. Conversely, closing the screen does not establish that no money moved. Support should be able to explain the sequence without immediately asking the customer to try again.
An acceptance card for confusing situations
| Test situation | What to request | Handover question |
|---|---|---|
| Leaving during authentication | A retained order and understandable state on return | Where did the displayed state originate? |
| Delayed provider confirmation | Visible waiting and an assigned follow-up step | Who reviews an extended wait? |
| Closing the payment window | A distinction between closing the interface and confirmed cancellation | Was the existing attempt checked? |
| Another customer press | A clear relationship to the order and previous attempt | How is an unintended collection decision prevented? |
| Success arriving after departure | An updated booking and retrievable outcome | What will staff and the customer see later? |
This proposed buyer card does not prescribe universal gateway status names. Ask the implementer to complete it for the selected payment method and booking process. Avoid treating every delay as rejection or promising a confirmed appointment before the confirmation policy you approved has been satisfied.
Separate screen restoration from payment evidence
Android documentation explains that the system may terminate an application process in the background. Retaining the previous display improves the return experience, but cannot establish that a payment occurred. Request a demonstration that closes the app and retrieves the order by reference, rather than leaving it open throughout.
Stripe guidance recommends server-side monitoring to trigger fulfillment after payment because customers may leave before completion. Discuss that principle without treating it as proof that the provider supports your business or country. Account eligibility, payment-method availability and relevant terms require separate verification before contracting.
What should staff do when screens disagree?
In this example, a customer might call while an attempt remains processing. Request a restricted support view showing the order reference, known state, last verification and permitted next step, without exposing sensitive payment data. Asking customers for bank-statement images should not be the only operational response.
Also define who may change the appointment or hold the visit while the outcome becomes clear, and how the reason is recorded. A later financial event such as a refund or dispute needs its own follow-up policy; a successful payment attempt does not guarantee that the financial position can never change.
Discuss the possibility that a temporary appointment hold expires before confirmation arrives. Who offers an alternative, and what appears if the slot is no longer available? Separate team-capacity handling from financial interpretation, recording the decision so a delay cannot become a promise of unavailable service.
Make testing a deliverable
Request suitable test data without real collection, an expected outcome for every situation and evidence connecting interface behavior to server records. Specify agreed devices, versions and responsibility for resolving discrepancies. A successful video is insufficient if the order cannot subsequently be found or its history explained.
The retry acceptance guide covers shared uncertainty and duplication concerns, while the mobile-app proposal guide defines app, administration and server boundaries. Attach this card when requesting mobile application development from Nextwave so that return behavior and exceptions can be compared within the proposal.
Sources and example limits
Stripe guidance on accepting Android payments and monitoring status, and Android documentation on saving UI state, were opened on 4 November 2026. The card and example are editorial proposals without actual payment testing. AI assisted preparation, with information and translation review.