Receipts

Most integrators already generate a purchaser or merchant receipt in their POS or checkout flow. When you add Bead payment methods, you should extend your existing receipt template with the additional Bead required fields for the payment method used.

Receipts can be delivered in any channel you support such as printed receipt, email, SMS, in app receipt view, or portal access.

Overview

• Primary approach: add Bead required fields to your existing receipt template

• Timing: make the receipt available when the payment reaches a final state

• Availability: the receipt must be retrievable after completion

• Retention: retain receipt records and delivery or access logs for at least 7 years

• Optional: Bead can deliver receipts via emailReceipt and smsReceipt flags on Create Payment

When to issue the receipt

You should generate or finalize the receipt after you confirm the final outcome of the payment.

Common patterns:

• Webhooks: update your order and generate the receipt when you receive a final status event

• Polling: generate the receipt after you confirm the final status via the tracking endpoint

If you are not sure which statuses are considered final in your flow, review Payment Statuses.

Receipt delivery models

Integrator delivered receipts (most common)

You deliver the receipt using your existing mechanism. Bead expects that your receipt content, timing, and retention meet the standards in this page.

Bead delivered receipts (optional)

If you prefer Bead to send the receipt message, enable emailReceipt and or smsReceipt when creating a payment.

These flags control delivery only. They do not change the required receipt content standards.

Receipt standards

Timing

A receipt should be available promptly when the payment reaches a final state in your system.

Availability

If you suppress email or SMS receipts, you must provide an alternative way to retrieve receipts, for example portal access, in app history, or back office search.

Retention

Partners must retain receipts and evidence of delivery or access logs for at least 7 years and make them available for audit and regulatory review.

Support contact

Receipts must include a support contact for transaction inquiries.

Required receipt fields

Include these fields on all receipts. Some fields may not apply depending on payment method.

Field	Notes
Receipt identifier	Your receipt id
Transaction timestamp	Date and time shown to the purchaser or merchant
Payment code	Use the Bead paymentCode as the primary Bead reference value on receipts
Amount paid	Total amount charged to the purchaser, shown in the currency or asset used
Currency or asset	For example USD, USDC, BTC
Exchange rate	Include when a conversion occurs, such as crypto to fiat
Fees	Itemize any fees if applicable
Taxes	If you collect taxes, include them as normal
Merchant or payee descriptor	A name that matches the checkout context
Payment method label	A short label that the purchaser understands, such as crypto, wallet, or card
Final status	Completed, cancelled, expired, invalid, or other final status you display
Network	Include when relevant, such as Base, Solana
Source account	Recommended when applicable: a truncated source identifier. Example for crypto: originating wallet 0x12ab...89cd
Support contact	Your support channel such as email or phone

Notes:

• If you display a wallet address or other sensitive identifier, Bead recommends truncating to improve readability and reduce risk.

Optional Bead delivered receipts

If you want Bead to send the receipt message, enable these fields when creating a payment:

• emailReceipt: send a receipt to the email address you provide for receipts

• smsReceipt: send a receipt to the phone number you provide for receipts

If you do not enable these options, you are responsible for delivering the receipt through your own channels.