Treat authorization, physical activation, and fulfillment confirmation as three separate events, and give each its own state. An approved payment only tells you the processor said yes. It does not tell you the machine started, and a pulse alone does not prove it either. Recovery design is deciding what the system does when one of those events is missing.

This guide covers the states, the failure modes, and the recovery rules that keep customers and operators out of trouble.

Three events, not one

Event What it proves What it does not prove
Authorization The processor approved the amount That the machine received credit
Activation Your system sent the credit signal or command That the machine accepted it or ran
Fulfillment confirmation The machine reported a start or delivery, through a status input or protocol feedback Anything, if the machine gives no feedback

Some interfaces give structured feedback and some do not. For the interface differences, see Understanding MDB Levels and Modernize Your Pulse-Based Systems.

Transaction states

Give every attempt an explicit state and persist it before the next step. These names are illustrative.

▸ Created: the attempt exists with a unique transaction ID.

▸ Authorizing: the request is with the processor.

▸ Approved: the processor approved, nothing activated yet.

▸ Activation sent: the credit signal or command went out.

▸ Fulfilled: the machine confirmed a start or delivery.

▸ Unresolved: activation was sent but no confirmation arrived.

▸ Reversed or refunded: money was returned by policy.

▸ Reconciled: records agree across processor, system, and machine data.

The recovery sequence

[embedded content: unattended payment recovery sequence, 7 steps]

Steps 1 to 3 are the payment, step 4 is activation, and step 5 is the only fulfillment signal. If it never arrives, the transaction stays unresolved and steps 6 and 7 apply your reversal or refund policy using the same transaction ID.

Failure modes and safer designs

Failure What happens Safer design
Lost processor response You do not know whether it was approved Query status or reverse using the same transaction ID before any retry
Device reset after approval The reader or controller restarts mid-flow Persist state before activation, then resume or resolve on restart
Connectivity loss after approval Activation cannot be sent or confirmed Hold with a timeout, then reverse or refund if the machine never activated
Duplicate request A second tap or an automatic retry fires Use an idempotency key or a unique transaction ID per attempt
Activation sent, no confirmation The outcome is ambiguous Mark unresolved, check any sensing input, and resolve by policy
Machine started, system unaware The customer was served but the record is missing Reconcile against processor and machine data

Reversals and refunds

A reversal cancels an authorization before it settles. A refund returns funds after settlement. Terminology and availability differ by processor, so use your processor's definitions and decide in advance which one the system issues in each state. Customers should hear the result in plain words, not wait for a manual review.

Reconciliation

Compare three sources on a regular schedule: processor records, your transaction states, and machine data where it exists. Anything unresolved needs an owner and a clear next action. A pulse alone does not confirm fulfillment, so do not treat it as a fulfillment record.

FAQs

Does an approved payment mean the machine started?

No. Approval is the processor's answer. Activation and fulfillment are separate events your system must track.

Can a pulse confirm the cycle started?

Not by itself. A pulse is a credit signal. You may need a separate status input or other sensing to confirm a start.

Should I retry automatically?

Only with an idempotency key or unique transaction ID, so a retry cannot create a second charge.

Who decides between reversal and refund?

Your policy and your processor's capabilities. Define it per state before launch.

Next step

If you can share your machine interface, processor, and current failure handling, we can walk through where recovery gaps are likely. Start at the unattended systems page.

Sources

▸ Understanding MDB Levels and How They Shape Vending Payments

▸ Modernize Your Pulse-Based Systems with Cashless Payments