Affirm’s basic mechanics create a timing gap that a lot of merchants don’t think through until it’s already causing confusion in their books: Affirm pays you, the merchant, upfront and in full when an order is placed, while the customer pays Affirm back over an installment schedule that might run months. That gap between “we got paid” and “the customer has actually paid for this” is the entire integration problem worth solving.
Why this isn’t just another payment method
Treat Affirm like a standard payment gateway and you’ll book revenue and cash the moment the payout hits, which might be completely wrong depending on your revenue recognition policy. If the order includes future obligations — a service period, a subscription component, deferred fulfillment — recognizing all of it on day one because Affirm happened to fund the whole amount upfront can misstate revenue in a way that has nothing to do with when the customer actually gets or pays for what they bought.
This is a case where the integration’s job isn’t just data movement — it’s applying your actual accounting policy correctly to a payment mechanism that doesn’t naturally map to it. We don’t assume an answer here; we work through your existing revenue recognition treatment first and build the Affirm sync to match it, rather than defaulting to “recognize on payout” because that’s the easiest technical path.
What syncs
- Orders and their associated installment schedules
- The merchant payout Affirm sends upfront
- Affirm’s merchant fees
- Refunds
- Order-to-payment matching, so a given sales order ties back to the specific Affirm payout that funded it
Refunds are where this gets genuinely tricky
A refund on a normal card transaction is simple: money goes back, the GL entry is straightforward. A refund on an Affirm order is not, because the customer may be partway through their installment schedule when the refund happens. Affirm has already paid you the full amount upfront, the customer has only paid some installments so far, and now a refund needs to unwind all of that correctly — adjusting what you owe back, accounting for Affirm’s own fee treatment on the refunded amount, and making sure your receivables don’t end up overstated for an order that’s no longer fully valid.
Getting this wrong doesn’t usually show up immediately. It shows up months later, when someone’s trying to reconcile why a refunded order still has open balances that don’t make sense, and the root cause traces back to a refund event that wasn’t mapped correctly against the installment structure.
How we scope this
The first real conversation in scoping an Affirm integration isn’t technical — it’s an accounting conversation about how your business wants to recognize revenue on installment-funded orders, and how refunds should be treated relative to Affirm’s payout timing. Once that’s settled, the technical build is fairly contained: sync orders and payouts, map fees to the right accounts, and build refund logic that correctly unwinds a partially-paid installment order rather than treating every refund like a same-day cash transaction.
We also make sure order-to-payment matching is solid from day one, since Affirm orders need to trace cleanly back to their funding payout for any audit or reconciliation work down the line — a loose match here is the kind of thing that’s cheap to fix during the build and expensive to untangle a year later.
If you’re offering Affirm at checkout and haven’t yet had the revenue recognition conversation, that’s worth doing before the integration, not after. See the full Affirm integration guide for more, or talk to us about your specific setup.