Buyer Wallet

Buyer Wallet enables platforms to give their buyers a stored-value balance that can be funded, spent, and withdrawn within the platform ecosystem.

Through the wallet, platforms can credit refunds instantly, hold a persistent buyer balance, offer that balance as a tender at checkout, and return funds to a buyer's own verified bank account. The wallet is provisioned against a verified participant profile and operates as a restricted-use stored-value product: funds can be spent with the platform or withdrawn by the buyer and are not transferable to third parties.

Buyer Wallet is a fund and balance capability. It depends on participant onboarding to establish the buyer record and should not be confused with platform settlement accounts or platform-level ledger configuration completed during implementation.

Why Buyer Wallet Matters

Platforms that rely on card, bank transfer, or wire rails to return money to buyers carry settlement lag, reversal cost, and a poor refund experience. A wallet moves that activity on platform.

Buyer Wallet helps platforms:

• Credit refunds instantly through book transfer instead of a settlement rail
• Reduce reversal and return costs on refund use cases
• Create a persistent buyer balance that improves retention and repeat purchase
• Meet money-out obligations by supporting buyer-initiated withdrawal
• Establish the balance foundation for future embedded finance capabilities

Wallet Lifecycle

The wallet lifecycle spans provisioning, funding, spend, and money-out. Each stage is API-driven, and asynchronous outcomes are confirmed by webhook.

Each stage is API-driven; asynchronous outcomes are confirmed by webhook

The wallet is provisioned once and reused. Platforms do not recreate wallets to enable additional funding or money-out capability.

Execution and Status Handling

Buyer Wallet operations may complete immediately or continue processing asynchronously. Each request returns an initial status and transaction identifier. If processing is still underway, the operation remains pending until a final outcome is delivered through a webhook.

Platforms should use webhook events as the source of truth for final transaction status. Where idempotency is supported, retries for the same logical operation should reuse the original transaction identifier to avoid duplicate processing.

Synchronous acknowledgement and asynchronous completion

Webhook events are the source of truth for final transaction status. Where idempotency is supported, retries for the same logical operation should reuse the original transaction identifier.

Progressive Verification Model

Buyer Wallet supports a progressive verification model that enables platforms to offer a low-friction refund experience without requiring full identity verification at initial enrollment. A buyer may receive credits, spend an available balance, and view balance and transaction history after initial screening. Full verification is required when the buyer's activity, requested capabilities, risk indicators, or applicable compliance requirements trigger additional verification.

Screening enables wallet access. Further checks follow activity, risk indicators, or regulatory thresholds

Verification requirements are applied progressively based on customer activity, risk indicators, capability enablement, and regulatory obligations.

Initial screening is performed at enrollment and is not repeated for every subsequent credit unless required by applicable compliance rules. The buyer's cumulative activity is monitored continuously, and additional verification may be triggered based on platform-configured thresholds, risk indicators, requested capabilities, or regulatory requirements.

Integration Guidance

• Derive buyer entitlement from verification tier, not from participant status alone. An active participant at Tier 1 is entitled to a narrower capability set than one at Tier 2.
• Track cumulative credit volume on your side so that escalation is never a surprise to the buyer mid-journey.
• Verification is asynchronous. Submit the verification request and track the outcome through the decision endpoint and webhook events.

Where Buyer Wallet Fits

The verification outcome determines which wallet capabilities can be enabled.

Platforms configure balance caps and limits against these positions. Where a settled load is subsequently returned after the buyer has already spent against it, the resulting exposure is isolated to a dedicated ledger position and surfaced to the platform for collections action.

Credits, checkout spend, and withdrawal move against distinct balance positions

Where a settled load is later returned after the buyer has already spent against it, the resulting exposure is isolated to a dedicated ledger position and surfaced to the platform for collection's action.

Integration Approach

Buyer Wallet is integrated through APIs, with the platform owning the buyer-facing experience. An embedded SDK may be used where secure bank-account capture and verification are required. Transaction and verification outcomes are communicated through API responses and webhook events.

Common Business Outcomes

Platforms use Buyer Wallet to:

• Return funds to buyers instantly rather than through a settlement rail
• Maintain a persistent buyer balance within the platform
• Offer the balance as a tender at checkout
• Support buyer-initiated withdrawal to a verified bank account
• Tokenize and reuse buyer payment sources without handling sensitive data
• Apply screening, verification, and transaction monitoring against wallet activity
• Reconcile wallet activity against platform settlement and reporting