Reference · built on requestConnectorPayments, billing & fraud

Affirm

Buy now, pay later transactions, events, and settlement lines from Affirm's Transactions and Settlements APIs.

Request accessPricing ↗

About

Affirm is a buy now, pay later lender. After a shopper completes Affirm checkout, the merchant authorizes a transaction, then captures, voids, refunds, or updates it through the Transactions API. Each change is recorded as a transaction event, and settlement events show what Affirm paid out net of fees.

Through Fibric, an operator reads transactions and settlement events and proposes the next step against your order system: capture when goods ship, void a cancelled order before the authorization lapses, or refund a return. You approve. The connector makes the call once, with the request key Affirm asks for on retries, and keeps the event id it returns.

This is a reference listing. It documents what Fibric would read from Affirm and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Transactions from GET /api/v1/transactions and GET /api/v1/transactions/{id}, with status, amount, amount_refunded, and authorization_expiration
  • Transaction events from GET /api/v1/transactions/events: type, amount, fee, fee_refunded, and created
  • Settlement events from GET /api/v1/settlements/events, filtered by merchant_id and date, with event_type values such as loan_capture, loan_refund, and dispute_opened
  • Per-line settlement amounts: sales, refunds, fees, transaction_fees, total_settled, deposit_id, and effective_date
  • Settlement event summaries from the List Settlement Event Summaries endpoint
  • Transaction states authorized, captured, voided, partially_refunded, refunded, disputed, and dispute_refunded

Proposed actions

  • Target capability: propose capturing an authorized transaction through POST /api/v1/transactions/{id}/capture
  • Target capability: propose voiding an authorized transaction through POST /api/v1/transactions/{id}/void
  • Target capability: propose a full or partial refund through POST /api/v1/transactions/{id}/refund; omitting amount refunds the remaining balance
  • Target capability: propose updating a transaction's order id, shipping carrier, and tracking through POST /api/v1/transactions/{id}/update

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Capture when the order ships

    When your order system marks a shipment, the operator proposes the capture and the update call that carries carrier and tracking to Affirm. You approve; both are made once and the event ids kept.

    With Tracking Sync

  • Void before the 30 days run out

    Authorized transactions with no capture and an authorization_expiration inside the next few days are listed. For cancelled orders the operator proposes a void; for the others it flags the deadline.

    With Cancellation Window

  • Tie settlement lines to orders

    Each settlement event carries order_id, transaction_id, deposit_id, and total_settled. The operator matches them to orders and refunds in your ledger and proposes journal entries for the fees.

    With Payout Reconciliation

  • Refund a return within the balance

    For an approved return, the operator reads amount and amount_refunded, proposes a partial refund that fits the remaining balance, and records the refund event and its fee_refunded.

    With Returns Triage, Refund Policy

Requirements

  • An Affirm merchant account and access to the Merchant Portal to read the API keys
  • Separate sandbox and production keys; sandbox calls go to sandbox.affirm.com and production calls to api.affirm.com
  • Your Affirm Merchant ID, required as a filter on settlement event requests
  • HTTPS only; calls over plain HTTP fail
Authentication
HTTP Basic authentication with the public API key as username and the private API key as password, both read from the Merchant Portal.

Limits

  • An authorization expires after 30 days by default; an expired transaction is voided and no further action can be taken on it.
  • Settlement events default to the last 30 days and return at most 1000 rows per page.
  • This listing reads state on request from the Transactions and Settlements APIs; it does not rely on push notifications from Affirm.
  • A refunded amount is withheld from your next settlement rather than returned as a separate payment.

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Affirm ↗

Questions and answers

Does Affirm support partial refunds?
Yes. POST /api/v1/transactions/{id}/refund takes an optional amount in cents. If the request omits it, the entire remaining amount on the transaction is refunded. The response is a refund event with amount, fee, currency, and created.
When does the shopper start paying after capture?
Affirm's transaction states guide says the user begins payments 30 days after the capture, and that Affirm transfers funds to the merchant within 2 to 3 business days.
How does the connector see what Affirm paid out?
Through GET /api/v1/settlements/events, filtered by merchant_id and a date range. Each event carries an event_type, sales, refunds, fees, total_settled, deposit_id, and effective_date, which is enough to match a deposit to the orders inside it.
Ask about Affirm

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Affirm through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy