Three records must tell the same story
PayIn defines reconciliation as matching payment records with internal business records. Its guide asks whether the customer paid, the order was fulfilled, the account was credited and accounting agrees.[7] These are separate outcomes. A transaction onchain does not prove that stock was released, and a successful webhook response does not prove a ledger entry was committed. Our recommendation is to reconcile the order obligation, the observed payment and the resulting business action rather than merely compare two dashboard totals.
Create a joinable record, not a screenshot folder
PayIn lists merchant order or invoice ID, payment ID, customer reference, chain and token, expected and received amounts, transaction reference, confirmation time, webhook IDs and fulfillment or crediting records.[7] Use those as a starting point for a documented export schema. Preserve original values and units. Include a precise transfer or event reference when a transaction contains multiple relevant events. Keep customer information to what is necessary and restrict access. An image of a dashboard cannot replace stable identifiers that another operator can join.
Keep settlement models apart
Stripe’s current documentation states that completed stablecoin payments settle into its balance in local currency. The applicable currency depends on the current product and merchant region; its USD presentment currency is not a universal settlement rule.[1] That means the customer's token transfer, the payment provider record and the business's settlement record can use different representations. Do not sum token units, invoice currency and bank receipts into one undifferentiated total. Our recommendation is to document which source owns each value and to retain conversion and fee information when the actual provider supplies it. This guide proposes an operational record structure, not a jurisdiction-specific accounting treatment.
Work from an exception queue
PayIn identifies late payments, underpayment, overpayment, wrong-network payments, failed internal fulfillment and duplicated webhook processing as mismatch cases.[7] Start with the records that fail a defined rule, assign an owner and preserve the reason for any manual adjustment. Stripe’s duplicate-delivery guidance also explains why event counts alone cannot stand in for payment counts.[2] Record whether an exception concerns detection, confirmation, allocation, fulfillment or refund. Different failure classes require different evidence; one generic 'paid' flag hides the investigation.
Close the review with evidence
A suggested daily procedure is to compare the authoritative payment export with internal orders and ledger entries, investigate unmatched items, review manual changes and record unresolved exceptions with an owner and next action. PayIn recommends a lightweight daily reconciliation habit for active merchants.[7] Do not force a match just to close the report. Keep a correction trail that explains what changed and why. Have a second operator reconstruct one completed payment from the export as an acceptance exercise. This is a proposed control, not an audited result or tax recommendation.
Sources & currency
Continue reading
Write the stablecoin refund policy before the first sale →
All field guides →