Platform & controls
Why the record WaltzPay gives you back can be trusted: what the platform actually enforces, and what it deliberately does not attempt.
Built
Controls in place
Deterministic provider selection
Which provider a collection goes to is decided by explicit, configured rules. The same inputs produce the same decision. Nothing is learned, inferred or self-tuning, and no model chooses a route.
One canonical record
Each collection has a single normalised record that owns its identity, independent of the provider handling it. Provider-specific identifiers hang off that record rather than replacing it.
Idempotency and duplicate-charge protection
A retried request does not become a second charge. A collection request that is replayed resolves to the collection it already created.
Explicit unresolved outcomes
When a provider has not made an outcome final, or WaltzPay cannot determine what the provider did, that state is recorded as its own thing. It is never collapsed into an ordinary pending state and never reported as success.
Attempt-level history
Each submission to a provider is recorded as its own attempt with its own status, so the history of a collection can be reconstructed rather than inferred from its current state.
Reconciliation evidence
The provider evidence needed to reconcile a collection is captured and retained, so a reconciliation can be performed against records rather than against recollection.
Change control
Production routing configuration is a governed change, not an operational convenience. Changes are reviewed before they take effect.
Tenant isolation
A merchant identity can only read its own collections. Queries are scoped by merchant and collection together, and a record belonging to another merchant is indistinguishable from one that does not exist.
Not built
Capabilities we do not have
A payments platform that stays quiet about what it cannot do invites the reader to assume it. So we name it.
See the full list of capabilities not yet built
Resilient or self-healing routing
WaltzPay does not automatically route around a degraded or failing provider. There is no automatic failover between providers. Recovering from a provider problem is an operator action.
Optimised or intelligent routing
There is no cost, authorisation-rate or latency optimisation, and no machine-learned routing. Selection is deterministic and configured.
Universal multi-provider orchestration
Orchestration is not available across providers generally. One provider connector is in controlled implementation. A second exists in the codebase but is not certified for production and is not offered.
Complete three-way reconciliation
The evidence layer for reconciliation exists. Reconciliation itself is not complete, is not automatic, and is not claimed as a finished capability.
Production-ready Paystack settlement ingestion
Paystack settlement ingestion is not production-ready and must not be relied on. It is named here so its absence is explicit.
Refunds, disputes and settlement operations
No refund, dispute or settlement capability is offered to merchants at this stage. Where underlying services exist they are not exposed, and authority for refunds is still an open decision internally.
Boundary
Who does what
WaltzPay is not a licensed payment processor, acquirer, money transmitter or deposit-taking institution. Payments are processed and settled by licensed payment providers under their own authorisations and their own terms. WaltzPay does not hold, safeguard, pool or lend customer or merchant funds, and does not operate customer balances.