Reference · built on requestConnectorPayments, billing & fraud

Afterpay

Payments, captures, refunds, courier updates, and disputes from the Afterpay Online API for AU, NZ, CA, and UK merchants.

About

Afterpay is a buy now, pay later provider. The Afterpay Online API v2 covers checkouts, payments, refunds, courier details, and disputes for merchants in Australia, New Zealand, Canada, and the United Kingdom, served from global-api.afterpay.com. Every payment carries a status of APPROVED or DECLINED and a paymentState such as AUTH_APPROVED, PARTIALLY_CAPTURED, CAPTURED, or VOIDED.

Fibric operators read payments and disputes on request and propose what follows: capture a deferred authorization before it expires, refund a return, add courier tracking, or respond to a dispute with evidence. You approve. The connector sends each call once, with a requestId so a retry cannot repeat it, and files the payment events Afterpay returns.

This is a reference listing. It documents what Fibric would read from Afterpay 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

  • Payments from GET /v2/payments, filtered by fromCreatedDate, toCreatedDate, tokens, ids, merchantReferences, and statuses
  • A single payment by order id or by checkout token, with its events, refunds, and courier object
  • paymentState transitions AUTH_APPROVED, AUTH_DECLINED, PARTIALLY_CAPTURED, CAPTURED, CAPTURE_DECLINED, and VOIDED
  • Disputes from GET /v2/disputes/{dispute_id}: reason, amount, status, and responseDueBy
  • Dispute status values needs_response, under_review, won, lost, merchant_refunded, and merchant_voided
  • Merchant configuration from the Get Configuration endpoint

Proposed actions

  • Target capability: propose capturing a deferred payment, in full or in part, through POST /v2/payments/{orderId}/capture
  • Target capability: propose voiding an authorized payment through the Void Payment endpoint
  • Target capability: propose a full or partial refund through POST /v2/payments/{orderId}/refund
  • Target capability: propose updating courier name, tracking, shippedAt, and priority through PUT /v2/payments/{orderId}/courier
  • Target capability: propose responding to a dispute with evidence through POST /v2/disputes/{dispute_id}, or accepting it through the Accept Dispute endpoint

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

What you can build

  • Respond to a dispute once, correctly

    A dispute in needs_response has a responseDueBy date. The operator drafts the shipping, refund policy, and product evidence and holds it for approval, because Afterpay accepts a single submission.

    With Chargeback Evidence

  • Capture before day 13

    Payments still AUTH_APPROVED near the 13-day expiry are listed. The operator proposes capture for shipped orders and void for cancelled ones.

    With Order Risk, Cancellation Window

  • Refund a return inside 120 days

    For an approved return the operator proposes a partial refund with a merchantReference, checks the purchase date against the 120-day rule, and files the refundId.

    With Returns Triage, Refund Policy

  • Send tracking to the payment record

    When a shipment leaves, the operator proposes the courier update with name, tracking, and shippedAt so the payment shows delivery details.

    With Tracking Sync

Requirements

  • An Afterpay merchant account in Australia, New Zealand, Canada, or the United Kingdom with a Merchant ID and Secret Key
  • A User-Agent header on every request naming the integration, platform, merchant, and website, as Afterpay's request header rules require
  • TLS 1.2 or higher; sandbox traffic goes to global-api-sandbox.afterpay.com
  • For United States merchants, the separate developer platform at developers.cash.app, which this listing does not cover
Authentication
HTTP Basic authentication with the Merchant ID as username and the Secret Key as password, or an OAuth 2.0 client credentials Bearer token from merchant-auth.afterpay.com.

Limits

  • An authorization expires after 13 days and is then voided automatically; a voided payment cannot be captured.
  • Refunds cannot be created after 120 days from the date of purchase.
  • A dispute allows one evidence submission; once a 200 response is received the response cannot be changed.
  • Disputes are retrieved by id on request; this listing does not depend on Afterpay pushing dispute notifications.

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 Afterpay ↗

Questions and answers

Which regions does the Afterpay Online API serve?
Australia, New Zealand, Canada, and the United Kingdom, from global-api.afterpay.com for production and global-api-sandbox.afterpay.com for sandbox. United States integrations are documented separately at developers.cash.app.
How does the connector avoid a double refund on retry?
It sends a requestId and a merchantReference with each refund. Afterpay treats the operation as repeatable when both are present, so a retried request returns the original result instead of creating a second refund.
What states can a payment be in?
status is APPROVED or DECLINED. paymentState is one of AUTH_APPROVED, AUTH_DECLINED, PARTIALLY_CAPTURED, CAPTURED, CAPTURE_DECLINED, or VOIDED. A deferred capture returns 201 with the updated payment and a new entry in its events array.
Ask about Afterpay

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.