A branded wallet interface is only one part of a digital payment service. Before selecting a platform, define who operates the service, which users it supports, how money moves and which organisations provide the underlying services.
This is a technology procurement checklist. A platform demonstration does not establish authorisation to provide financial services or prove that a particular payment connection is available in your market.
Start with a concrete service model
Describe your customer and merchant groups, target country, intended currencies and the transactions you want to support. Explain how users would fund an account, make a payment, receive funds and request support. Identify the organisations responsible for those steps.
A focused use case is easier to evaluate than a request for every possible wallet feature. If the first release covers one customer group and a limited set of payment journeys, write those limits into the brief.
Ask what exists, what needs configuration and what must be built
| Area | Evidence to request | Decision to make |
|---|---|---|
| Customer experience | Actual screens and a demonstrated workflow | Which journeys fit your first release |
| Merchant operations | Acceptance, transaction and settlement views | Which operational roles are required |
| Administration | Staff access, review queues and reports | Who may perform each action |
| Integrations | Provider names, interface documentation and test access | What is confirmed versus dependent on third parties |
| Commercial scope | Deliverables, exclusions and recurring charges | What the proposal actually includes |
Request a module-by-module response marked available, configurable, additional development or unsupported. Ask the supplier to distinguish demonstration data from a live integration. This helps prevent assumptions from becoming contractual disputes later.
Map provider dependencies early
For identity verification, payments, mobile money, cards or remittance, identify the intended service provider and the access required to test the connection. Agree who obtains accounts, documentation, credentials and commercial arrangements. An API being publicly documented does not mean that production access has been approved.
Include provider onboarding, test environments and external review steps in the project plan. Keep operating permissions and jurisdiction-specific obligations with the appropriate qualified advisers and service partners.
Review exception handling and reconciliation
Ask to see what happens when a request times out, a transaction is pending or a provider sends a repeated notification. Agree the source of transaction status and how staff investigate discrepancies. Define reporting, reconciliation, settlement visibility and support responsibilities for the proposed operating model.
Use a written test matrix with expected outcomes for successful, unsuccessful and uncertain transactions. The point is to establish the behaviour of the proposed implementation, not to assume that every platform handles exceptions identically.
Make security evaluation part of acceptance
Identify staff roles, customer access boundaries, sensitive data handling, audit records and incident ownership. Ask how these controls will be evaluated and what evidence will be supplied. The OWASP API Security Project is a useful technical reference for API-risk discussions; citing it is not a certification or a substitute for testing your implementation.
Compare the complete commercial picture
Separate platform licensing or build costs from configuration, integration work, migration, hosting, ongoing support and third-party charges. Ask who owns the deployed configuration, who maintains each connection and what access or export options are provided at handover.
For a pilot, define participating users, the intended environment, supported journeys, transaction limits where applicable, test data, acceptance criteria and the decision required at its end. Agree the transition requirements before assuming that a successful demonstration can become a production launch immediately.
What to include in your demo request
- Your organisation and intended country of operation.
- Customer and merchant groups.
- Required payment journeys and currencies.
- Existing or proposed service partners.
- Essential administration and reporting tasks.
- Pilot objectives, dependencies and preferred timing.
Discuss a wallet platform around your use case
Review the Digital Wallet overview and bring your workflow and integration questions to a tailored discussion.
Request a Digital Wallet demo