How Affirm Reaches Your Checkout: Five Integration Paths

Affirm publishes its own map of this. Its developer documentation lists a family of direct merchant integrations: a Direct API integration, a virtual-card integration, a lighter drop-in, an in-store option, mobile SDKs and telesales. Its platform documentation adds two arrangements that run through somebody else, via a payment service provider or a prebuilt ecommerce-platform app. Its business site markets a third, digital wallets. And its annual report describes a fourth, in which Affirm issues a virtual card straight to a consumer who then shops at a merchant with no Affirm integration at all.

Grouped by what they mean for the business selling the offer, those collapse into five paths:

• Direct. The merchant integrates Affirm itself, under its own agreement with Affirm.
• Through a payment service provider. Affirm is enabled and configured inside a provider's platform.
• Through an ecommerce platform. A prebuilt app or plugin does the integration work.
• Through a digital wallet. Affirm appears inside a digital wallet such as Apple Pay® or Google Pay™ and reaches the merchant as an ordinary card.
• Carried in by the customer. A virtual card Affirm issued to the consumer, used at a checkout that knows nothing about it.

Ask four questions of each: who holds the agreement, what the merchant must do to be eligible, what the merchant controls, and how the money and the fees move. They separate the paths far better than the logo at checkout does, for a business selling coaching programs, agency retainers, med spa packages or home improvement work alike.

Affirm's onboarding documentation describes the sequence plainly. A developer who wants public and private keys first creates a merchant account and signs an agreement, and only then can Affirm activate it. The rest of the detail here comes from Affirm's own merchant resource hub, which sits behind a bot challenge as of 7 September 2026 and is therefore quoted from archived captures rather than from a link a reader can simply follow.

The account-creation article, captured in March 2025, says a business can see the merchant dashboard while it waits but that nothing will work, orders and APIs included, until the business has been evaluated and approved, and that Affirm aims to return an application decision within three to five business days. The eligibility and getting-started articles, captured in September 2025, set a short published bar — sell direct to consumers in the United States, Canada or the United Kingdom, with a matching bank account and an English-language website — say Affirm does not require a minimum volume for online sales, and add two conditions that weigh more on this audience than the volume line does: the website must be fully live before Affirm will explore a partnership, and it should be running on one of Affirm's supported ecommerce platforms. That is a real constraint for an operator whose sales motion is a booked call and a thin public page.

What the merchant gains is control and a console. Affirm's Direct API documentation describes a checkout the merchant embeds, giving it control of the front-end experience and the back-end transaction logic, and notes the flow can run on the merchant's own site in a modal or on affirm.com via a redirect. Promotional messaging on product and cart pages runs through Affirm.js using public API keys from the Affirm Merchant Portal, issued per administrator account. Custom financing programs exist, but Affirm says its Client Success team builds them and that not all merchants qualify.

What the merchant takes on is compliance work. Affirm's compliance guidance for new merchants — a December 2023 capture of the same resource hub — names the Truth in Lending Act, the Equal Credit Opportunity Act and the CAN-SPAM Act as obligations attaching to the merchant's own marketing, and asks that banners, landing pages and email go to Affirm's Merchant Care team before deployment. The agreement sits in the merchant's own legal entity, as a direct merchant account does.

One honest gap. Affirm's current prohibited business policy names no services, consulting or coaching category, though an older policy document still on Affirm's content delivery network does carry a high-risk services row. Both versions call the categories representative but not exhaustive, note they may be imposed through network rules or Affirm's financial services providers, and tell an uncertain business to ask Affirm directly. The list does not settle whether Affirm will take a coaching or consulting business, and Affirm says so itself.

Affirm is specific about where the work lives. Payment-service-provider integrations, it says, are typically configured within the provider's platform and may require merchant onboarding or additional enablement steps facilitated by the provider. Prebuilt platform integrations bring a simplified onboarding process, with setup detail sometimes hosted on the platform provider's own site rather than Affirm's, while Affirm still supports payment messaging, order management and transaction tracking. A merchant not on a supported platform is pointed at the Direct API.

Affirm's published index of platform integrations is an index of ecommerce carts and commerce clouds; as of 7 September 2026 no course platform, membership platform or coaching checkout appeared on it. That is a fact about what Affirm documents, not evidence that financing cannot work on such a checkout.

On approval the documentation is uneven. Some of Affirm's provider-specific setup guides carry a block headed Affirm requirements whose first line is that the merchant must be approved by Affirm; others carry no equivalent sentence and describe enablement through the provider's own account or relationship manager instead. Affirm does not publish one statement settling whether its approval is required on every provider route, so the reliable reading is the general one from its onboarding material: a merchant account and a signed agreement precede activated credentials. If a platform is arranging Affirm on a business's behalf, the question to put in writing is whose entity that agreement names.

Affirm states the merchant side in one sentence: its availability on Apple Pay lets merchants offer Affirm's flexible payments at checkout without the requirement of being integrated with Affirm, and a merchant that already has Apple Pay enabled has no technical lift to do. Its Google Pay page says the wallet integrations let eligible merchants offer Affirm without additional setup. Affirm markets this route itself, under a digital wallets heading on its business site. It is not a lesser version of Affirm; it is a different commercial arrangement.

Apple describes what happens on the customer's device: an installment offer on a card already in Wallet, or an additional pay-later option from a separate provider the customer applies to. In the second case the customer is transferred to that provider, and if the application is approved a card is added to the Wallet app to complete the purchase. Apple states that all installment plans are provided by the card issuer, that Apple provides technical services only, and that afterwards questions about the plan go to the card issuer or installment provider.

Google's developer material describes the same shape with different plumbing. When a shopper taps the Google Pay checkout option where the feature is on, a banner lists the available options and a new user onboards inside the wallet. Google states that the transactions are facilitated by the providers using a virtual card under the Visa network with applicable interchange rates, that the merchant processes the full payment as it would a normal card transaction, and that the provider finances it. Google adds that it is not the provider and does not determine eligibility or the options offered, and documents that a merchant can still tell what happened: the API response carries a description field naming the pay-later provider.

The two rails are not one mechanism. Affirm's Apple Pay guidance is essentially enable the wallet, while Google publishes card-parameter prerequisites an existing integration must already satisfy. Google also has a second surface with no equivalent found on the Apple side: Chrome autofill, where Affirm's documentation describes a customer inserting an Affirm virtual card number into a merchant's ordinary card fields, with the control Google documents sitting in the shopper's own browser settings. Coverage is unsettled and should not be stated as fact: Affirm's Apple Pay page, last updated in November 2025, says its availability there is online and in-app only, while Apple's January 2026 support page documents in-store installments on newer iPhone® software and its developer footnote says in-store availability varies by location. For the Google rail, Affirm's page and Google's guides name different devices and browsers.

Start with the sharpest published sentence in the subject. Google's developer FAQ asks whether merchants can select which providers or terms to offer, and answers no: Google Pay is an ecosystem enablement solution that gives users the choice of their preferred option. Google also documents that merchants in the verticals where the feature is most relevant, travel and retail being its examples, are opted in by default, and that some might be in a vertical that is not available for it. Nothing published maps coaching, consulting, agency, med spa or home-services businesses to either side of that line. The merchant's documented lever is the wallet as a whole: Google's API terms limit the isReadyToPay call to showing or suppressing Google Pay, and prohibit a purchase minimum, maximum or surcharge specific to it.

Apple publishes one control that runs earlier than the payment step: an upper-funnel merchandising element, a script tag plus a custom element, that lets a merchant highlight Apple Pay's flexible payment options on product and cart pages. The merchant supplies the placement and the amount, currency and country; it does not supply the provider list, which Apple fills from whatever it deems eligible. Apple's merchandising documentation warns that the element renders nothing when no eligible offer exists for that combination, with no error shown, and tells merchants to test across their full price range.

So the contrast between the routes is narrower than it first looks. A merchant on a wallet rail can place Apple's generic element. Affirm-branded messaging and prequalification are a different thing: they run through Affirm.js on public API keys from the Affirm Merchant Portal, which are artifacts of an Affirm account rather than of a checkout.

Two obligations run the other way: Apple's acceptable-use guidelines require a site accepting other third-party payment methods to offer Apple Pay at least on parity with them, and Google's integration checklist requires display parity too. And a genuine unknown — neither company publishes a merchant control for selecting or removing an individual installment provider inside its wallet. That is a statement about the documentation, not a finding that no such control exists.

In its annual report on Form 10-K for the fiscal year ended 30 June 2026, Affirm describes facilitating the issuance of virtual cards directly to consumers through its app, allowing them to shop with merchants that are not integrated with Affirm, and states that merchants are charged an interchange fee on each successful card transaction with a portion of that revenue shared with Affirm by its card-issuing partners.

Follow what that means at the checkout. The merchant holds no Affirm agreement, no Affirm account and no configuration. A card authorizes and captures like any other card. The customer is on an Affirm plan; the merchant's systems record a card sale. A business in that position can truthfully say a customer paid with Affirm and equally truthfully say it has no relationship with Affirm. Those are two different facts about the same transaction, and Affirm's own accounting keeps them apart.

Affirm's accounting reflects the same split: its annual report presents merchant network revenue and card network revenue as separate lines, and says merchant fee rates on each transaction are affected by whether a commercial agreement and negotiated pricing exist with the merchant. Whether a business holds its own agreement with Affirm is not a branding detail in Affirm's books; it is a different revenue line.

On the direct path Affirm's language is unusually plain: Affirm settles directly with the merchant. Its merchant help center, in archived captures from September and December 2025, says settlement reaches the merchant's bank account by ACH within one to three business days, and that Affirm pays the merchant upfront, in full, less the merchant discount rate and a transaction fee. One detail belongs in a finance team's notes: the settlement date shown in the dashboard is the date the transfer was initiated, not always the date the funds land. Affirm publishes the fee's shape and not its number, saying the rate depends on the program option, the business size and the risk profile.

The card and wallet paths move money on different plumbing. Affirm's virtual-card documentation tells the merchant to pass the card details through its existing gateway for authorization, capture and refund exactly like any other payment card, and its Apple Pay page says the merchant processes the card as it would any other Apple Pay transaction, so the sale lands in ordinary card processing. Affirm's settlement guidance for virtual-card and digital-wallet activity describes reconciling those transaction fees against debits taken from the merchant's bank account rather than netting them out of an Affirm payout, and notes that the merchant's own order identifier is empty for digital-wallet transactions. That guidance addresses merchants who already hold an Affirm relationship; what a merchant with none sees in its own reporting is not documented anywhere located.

What no source establishes is a direction. The direct path carries a merchant discount rate netted from an Affirm settlement; the card and wallet paths carry the merchant's own card-acceptance economics, interchange included; and Affirm's annual report says merchant fee rates vary with whether a commercial agreement exists. Anyone telling an operator that one of these routes is cheaper is asserting something none of the three companies has published.

These are diligence questions rather than a scorecard, and they work on any provider and any platform.

• Whose legal entity signs the financing agreement, and whose bank account is settled? Affirm describes a merchant creating an account and signing an agreement before credentials are activated, then depositing into that merchant's own account. On a card or wallet route the money arrives on the merchant's own card rails instead, and provider fees reconcile separately.
• Whose console holds the API keys? Affirm issues four keys per administrator account, says only administrators can manage them, and ties Affirm-branded messaging to them. Ask whether the business is an administrator.
• Modal or redirect, and before or after the payment step? Affirm says the flow can run in a modal or via a redirect to affirm.com, and that messaging can sit on a homepage, product or cart page. On the wallet rails the option surfaces only after the shopper taps the wallet button, and for a high-ticket offer sticker shock happens on the sales page, not the payment page.
• Where is the program documentation published, and who maintains it? Affirm publishes its merchant and developer documentation openly. Ask any provider or platform where its equivalent documentation lives and read it before building a checkout around it.
• Does the route cover the way the business bills, and the size it bills? Apple and Affirm both say paying over time on Apple Pay may not be available for all purchase types, naming subscriptions and recurring transactions, and Google publishes a per-provider cart floor and ceiling for its rail. Approved amounts and terms are set by each provider under its own underwriting and vary by applicant; what PayFull publishes about each is on the Affirm page and the provider comparison.

None of this makes the wallet rails a worse product. Affirm markets them, Apple and Google document them, and for a business selling to phone-first buyers they add reach for almost no build work. It makes them a different product, with the provider relationship outside the merchant's own entity and the presentation outside its control. PayFull is not a lender. It does not underwrite, is not a broker or intermediary, and has no authority, control or influence over any financing provider's decisions, rates, terms, approvals or denials; every application is decided by that provider under its own underwriting. What an operator controls is which arrangement its checkout is built on, and whether it knows the answer before a customer asks.