White Label Processing

Overview

White Label Processing begins when the merchant submits amount, pricing currency, Pay Currency, network, lifetime, and optional settings to the provider’s white-label endpoint.

The response supplies the address, expected crypto amount, rate, expiration, QR data, and tracking identifier. The merchant stores this data and renders its own interface rather than redirecting to a provider-hosted payment page.

After the payer sends funds, the provider monitors the blockchain and sends or exposes payment status. The merchant verifies callbacks, updates its Payment State Machine, and triggers order or balance actions idempotently.

Processing must handle underpayment, overpayment, expiration, late transfer, wrong network, provider timeout, duplicate webhook, refund, and manual acceptance. The branded interface should display the real state rather than infer completion from a wallet submission screen.

Reconciliation compares provider payment information, blockchain evidence, merchant order data, fees, conversion, and net proceeds. The full audit trail should show which part of the process was performed by the merchant and which by the underlying provider.

The processing flow should use an internal canonical payment model rather than exposing provider response fields directly throughout the application. This allows validation, versioning, and controlled mapping when the provider changes an API field or status. The original response should still be retained for audit and support alongside the normalized internal record.

End-to-end tests should use real network or sandbox events to verify address display, expiry, underpayment, callback authentication, duplicate delivery, manual acceptance, and reconciliation. Unit tests alone cannot reveal inconsistencies between merchant and provider state.

Operational dashboards should show provider request latency, address-generation failures, callback lag, stuck payment states, manual actions, and reconciliation differences.