Platforms and marketplaces
Explore a card programme designed for your platform model.
Start with the participants, permitted use and proposed movement of funds rather than a predetermined feature list.
Programme design, not a predetermined feature list. Final scope depends on the business, intended use, participating entities, jurisdictions and approval by the relevant providers.
Platforms and marketplaces
Define participants and fund flows before discussing features.
The platform model determines which relationships, responsibilities and onboarding questions need review.
- 01 / Ecosystem
Platform participants
- Participant types
- Commercial relationships
- Business reason for card use
- 02 / Programme
Permitted use and funds
- Proposed source of funds
- Allocation responsibilities
- Activity outside scope
- 03A / Experience
Participant card journey
Onboarding and card requirements are documented without assuming availability.
- 03B / Operations
Platform administration
Authorised roles, exceptions and support responsibilities are mapped to the programme owner.
- 04 / Feasibility
Programme service parties
Branding, integration and card services depend on approved scope and responsible providers.
- 05 / Oversight
Participant activity records
Transactions and programme events return to the review model agreed for the platform.
Model snapshot
Make the operating model visible.
These three questions establish the structure that the rest of the programme needs to support.
- Who uses it
- Approved participant groups defined by the platform programme
- Who funds it
- The approved programme funding source documented in the fund flow
- Who controls it
- The programme owner and authorised operational roles
Design considerations
Questions to settle before implementation.
The programme brief should explain purpose, responsibility and exceptions in terms the business and programme providers can assess.
Participant definitions
Identify every proposed participant type, its relationship to the platform and why it may need a card.
Permitted use
Document the intended business purpose, expected purchases and activity that should fall outside the programme.
Proposed fund flow
Trace where funds originate, how they are allocated and which party is responsible at each stage.
Onboarding and delivery
Define participant information, branding and integration requirements for feasibility review without assuming availability.
Operating flow
Turn the concept into a programme path.
Describe the model
Document the platform, its participants, commercial relationships and the purpose of the proposed programme.
Map value and responsibility
Set out the proposed fund flow, participant obligations, programme ownership and oversight requirements.
Assess feasibility
Review the model for regulatory, risk, technical, commercial and onboarding requirements.
Plan approved delivery
If the programme is approved, agree the supported experience, implementation responsibilities and launch criteria.
Programme outcomes
A clearer basis for review and delivery.
Structured programme requirements
Participants, permitted use, funding and operating needs are converted into a coherent programme brief.
Documented responsibilities
The proposed obligations of the platform, participants and relevant service providers are made clear.
A review-led delivery path
Branding, integration and programme features are confirmed only after feasibility and approval.
Common questions
Before you begin.
Can the card experience carry our brand?
Branding requirements can be documented during discovery. Any supported branding depends on the approved solution, relevant parties and applicable terms.
Is an API or technical integration included?
Technical requirements can be assessed, but no integration method should be assumed before the solution and implementation scope are approved.
Can every platform participant receive a card?
No participation is automatic. Eligible participant groups and onboarding requirements are defined as part of the approved programme.
Programme discovery
Discuss this business model with us.
Tell us how your company operates, who needs to pay or get paid and what the solution should achieve.
Describe your platform model