Payment flow

Receipts and verification

How receipts capture successful settlement, how they relate to payment definitions, and how to use them for verification and reconciliation.

A receipt is the authoritative record of one successful OpenPayment settlement. It is the object you keep when you need proof, traceability, or supportability after payment has already happened.

Why receipts exist

OpenPayment deliberately separates configuration from outcome:

the payment definition says how a payment should work
the receipt says that a specific payment actually succeeded

Without that separation, reusable payment links would be hard to operate. A MULTI_USE, VARIABLE, or PROXY payment can be used many times, so each success needs its own durable record.

What a receipt proves

A receipt answers the questions that matter after settlement:

who paid
who received funds
how much was paid
which token and network were used
which transaction settled the payment
when the payment happened
which payment definition it came from

That makes the receipt the correct object for support, audit trails, and reconciliation.

Receipt fields that matter operationally

Field	Why it matters
`receiptId`	The unique identifier for this successful payment event
`paymentId`	Connects the receipt back to the original payment definition
`payer`	Identifies the wallet that authorized settlement
`payTo`	Identifies the recipient wallet
`amount`	The actual settled amount
`price`	The configured payment amount or suggested amount at creation
`transaction`	Links the receipt to the block explorer proof
`network`	Distinguishes Mainnet from Sepolia

For VARIABLE payments, the distinction between amount and price is especially useful:

price reflects the configured suggested amount
amount reflects what was actually paid

Receipts by payment type

Type	Receipt behavior
`SINGLE_USE`	At most one successful receipt
`MULTI_USE`	One receipt per successful reuse
`VARIABLE`	One receipt per successful payment, potentially with different amounts
`PROXY`	One receipt per successful settlement before the protected response is returned

This is the reason a receipt should never be treated as interchangeable with a payment definition.

How to inspect a receipt

Use the Receipt page and provide the receiptId.

The UI shows:

settled amount
token and network
settlement timestamp
payer and recipient addresses
transaction hash with explorer link

This is the fastest way to answer a support question such as "Did this customer actually pay?" or "Which wallet sent the funds?"

Relationship between payment ID, receipt ID, and transaction hash

These three identifiers are related, but they solve different problems.

Identifier	Use it for
`paymentId`	Looking up the original payment setup
`receiptId`	Looking up one successful payment event
Transaction hash	Independent onchain verification

A healthy operational workflow stores all three whenever possible.

Receipts and reconciliation

Receipts are the right unit for reconciliation because they map to individual successful settlements, not just payment intentions.

Use them to:

confirm payment completion
reconcile customer orders
review payer disputes
connect business records to onchain transfers
support finance or operations audits

If you are using reusable links, reconciliation against receipts is essential because multiple customers may use the same paymentId.

Receipts in `PROXY` flows

In a PROXY flow, the receipt proves the payment succeeded even if the protected response later indicates an application-level issue.

That means a complete support review for PROXY usually checks two things:

the receipt, to confirm settlement
the protected response, to confirm what happened after payment

This distinction is one of the most important operational details in the product.