Collections

The layer a business puts between itself and its payment providers, so it has one record and one place to look — not a payment provider itself, and not a merchant account.

Collections orchestration and routing for emerging-markets commerce.

How it works

Server to server, never browser to provider

1. A merchant’s own backend asks WaltzPay to collect a payment, authenticating with its own key. A browser never holds that key and never calls Collections directly.
2. WaltzPay selects which configured provider the collection is submitted to, using deterministic rules that a person configured and a person can review.
3. WaltzPay records the collection canonically — one normalised record, with its own identity, independent of which provider handled it.
4. The payer completes payment in the provider’s own hosted checkout. The provider holds the card details; WaltzPay does not.
5. WaltzPay tracks the attempt to a final outcome. Where the provider has not made the outcome final, WaltzPay holds it as explicitly unresolved rather than guessing.
6. WaltzPay retains the provider evidence needed to reconcile what was collected against what the provider reports, and reports it to the merchant’s finance, operations and risk owners.

Control principle

Never told a payment succeeded before it actually did

When WaltzPay submits a collection to a provider and the request returns, that return is not proof the customer paid (a response is not evidence of payment). The provider may not have reached a final position yet, and the connection may have failed after the provider acted but before WaltzPay heard about it.

Collections therefore keeps an outcome that is not yet final as its own distinct state. It is never merged into “pending”, and it is never reported as a success. Merging the two is how a payments system tells someone a payment succeeded when nobody knows whether it did.

Responsibilities

What Collections is responsible for

• Provider selection

  Chooses which configured payment provider a given collection is submitted to, using deterministic, explicitly configured rules. Selection is governed and reviewable — it is not learned, inferred or self-tuning.

• Canonical transaction records

  Keeps one normalised record per collection across providers, so a payment has a single identity regardless of which provider handled it.

• Controls

  Applies idempotency, duplicate-charge protection and explicit handling of outcomes that a provider has not yet made final.

• Reconciliation evidence

  Collects and retains the provider evidence needed to reconcile what was collected against what a provider reports.

• Reporting

  Makes the canonical record and its supporting evidence available to the finance, operations and risk functions that own the payment.

Availability

What is enabled, and for whom

WaltzPay Collections is in controlled implementation and pilot preparation. It is not generally available, and it is not open for self-service sign-up.

Not claimed

What Collections does not do

It does not hold, safeguard or settle money at any point — the licensed provider does.