How do payment operators track voids across providers?

Short answer

Each void should land on the transaction it cancels, next to the authorization it reverses. A single transaction record across providers and reconciliation views show which payments were voided before settlement and which became refunds.

In detail

Each void should land on the transaction it cancels, next to the authorization it reverses. A single transaction record across providers and reconciliation views show which payments were voided before settlement and which became refunds.

Why voids get lost

A void cancels an authorization before capture, so no money moves and no settlement line is created. Providers report voids in different ways: some as a reversal event, some as a status change, some only in a daily file. When an operator runs several acquirers, the same action ends up with several names, and finance cannot tell a void from a refund without opening each provider's portal.

One record per transaction

  • Every provider event is mapped to the same lifecycle: authorized, voided, captured, refunded, disputed.
  • The void sits on the transaction it cancels, with its timestamp and the person or rule that triggered it.
  • Reports can filter on voided transactions across providers in one query.

What finance gains

Reconciliation only has to explain the money that moved. Voided authorizations are excluded from expected settlement, so missing lines are not chased for nothing. Merchants also see, from their own portal, why a customer saw a pending amount disappear. Operators that store voids this way also spot patterns: a merchant that voids a large share of its authorizations usually has a checkout or inventory problem worth a call.

Still have a question?

Our team walks you through the platform with your use case on the table.

Book a demo