Ellipse Gradient for Header

Afterpay Integration Guide

Connect Afterpay’s HTTPS REST payment APIs and selected status callbacks with commerce, order, finance, and customer-service systems through Martini workflows and APIs.

Afterpay integration options at a glance

Afterpay’s online integration model is based on HTTPS REST APIs with JSON requests and responses. Merchant applications can create checkouts, retrieve payment or order status, capture authorized payments, void authorizations, and submit full or partial refunds. Afterpay also supports callback or webhook-style notifications for selected payment lifecycle events, subject to merchant configuration, product, and regional availability. Martini can consume these APIs, expose an internal payment API, transform commerce data into Afterpay structures, receive supported callbacks, and run scheduled reconciliation workflows. Merchant ID and secret key credentials are stored in Martini Secrets Management, with separate sandbox and production configuration.

Integration pointSupported by Afterpay?Common use casesHow Martini supports it
REST APIsYesCreate checkouts, retrieve or validate checkout information, capture authorized payments, void authorizations, retrieve payment or order status, and submit full or partial refunds.Martini can consume Afterpay REST endpoints from workflows, transform JSON payloads, apply validation and business rules, and expose an internal API for upstream applications.
Webhooks / outbound callbacksLimitedReceive selected payment lifecycle status notifications when callback support is enabled for the merchant, product, and region.Martini can expose a REST endpoint, validate and correlate notifications, deduplicate them, and trigger downstream workflows. Scheduled reconciliation can cover missed notifications.
AuthenticationYesAuthenticate online API requests with the merchant ID and secret key using HTTP Basic Authentication, with separate sandbox and production credentials.Martini stores credentials in Secrets Management, separates environment configuration, uses HTTPS, and prevents secrets from appearing in mappings, responses, or logs.
JSON payloadsYesExchange checkout, order, consumer, item, shipping, payment, and refund information through JSON request and response bodies.Martini maps internal models to Afterpay JSON, performs decimal-safe amount handling, validates required structures, and normalizes responses.
Bulk / async / batch APIsNot confirmedNo general-purpose Afterpay Online API bulk or batch mechanism was confirmed; payment and refund operations are generally individual actions.Martini can implement controlled scheduled reconciliation by reading local outstanding transactions and making individual status requests in bounded batches.
File / attachment APIsNoNo file-import, file-export, or attachment API was confirmed for Afterpay payment processing.Martini should use Afterpay’s JSON REST APIs and the merchant’s own file or database processes where file-based reporting is required.
Database / analytics accessNoNo merchant-facing database connection or general-purpose analytics query interface was confirmed.Martini can reconcile through Afterpay API calls and the merchant’s own database, but it does not rely on direct Afterpay database access.
Scheduled synchronizationYesReconcile authorized, captured, voided, refunded, or unresolved transactions and detect missed callbacks or state mismatches.Martini scheduler-triggered workflows can process outstanding local transactions, persist checkpoints, apply bounded retries, and update downstream systems.

How Afterpay exposes data and business events

Afterpay REST APIs

Afterpay’s documented online integration uses HTTPS REST endpoints with JSON requests and responses. The APIs support checkout creation, checkout or payment retrieval, capture, void, status retrieval, and full or partial refunds, subject to merchant permissions and regional configuration.

Martini implementation pattern

Martini implementation pattern: expose a controlled Martini API or receive an upstream commerce request, validate the financial and order data, call the appropriate Afterpay REST endpoint with credentials from Secrets Management, transform the response, and persist the resulting references and status.

Implementation sequence

Receive the checkout or payment operation request
Validate amount, currency, order number, and required fields
Map the internal model to the Afterpay JSON structure
Call the Afterpay REST endpoint over HTTPS
Normalize the response and store the Afterpay reference
Return the result or route an exception for resolution

Afterpay status callbacks

Afterpay supports callback or webhook-style notifications for selected payment lifecycle events when enabled, but coverage depends on merchant configuration, product, and region. The exact event set, security requirements, and retry behavior must be confirmed for the applicable account.

Martini implementation pattern

Martini implementation pattern: expose a protected REST endpoint, validate the callback according to Afterpay’s configured authentication or signature requirements, correlate the payment or order reference, acknowledge promptly, and process downstream updates in a workflow. A reconciliation workflow complements callbacks.

Implementation sequence

Receive the Afterpay status notification
Validate the configured authentication or signature
Check the payment or order reference and event state
Ignore or safely handle duplicate notifications
Update the local order or payment state
Queue or invoke downstream synchronization

Scheduled reconciliation

No general-purpose Afterpay bulk or batch API was confirmed. Merchants can therefore use individual status requests to reconcile outstanding transactions and detect missed callbacks, unresolved operations, or state mismatches.

Martini implementation pattern

Martini implementation pattern: a scheduler-triggered workflow reads local transactions requiring reconciliation, processes them in bounded batches, retrieves current Afterpay status, compares financial and lifecycle fields, and stores a durable checkpoint and exception outcome.

Implementation sequence

Start the scheduled reconciliation workflow
Select bounded outstanding transactions
Retrieve each current Afterpay status
Compare references, amounts, currency, and state
Update matched downstream records
Persist the checkpoint and route mismatches to exception handling

Common Afterpay integration patterns

Pattern 1: Create an Afterpay checkout

When to use this pattern

Use this pattern when a commerce application needs to offer Afterpay without embedding merchant credentials or Afterpay-specific orchestration in the client. Martini validates the order and maps customer, item, shipping, amount, currency, and redirect data before creating the checkout.

Integration direction
Shopify
Martini
Afterpay
Example Mapping
Afterpay FieldCanonical FieldTarget Field
orderNumbermerchantOrderIdorderNumber
totalAmountorderTotalamount
customer.emailconsumerEmailconsumer.email
lineItemsorderLinesitems
Martini implementation pattern

A Martini API receives the commerce request and starts a workflow. The workflow validates decimal-safe totals and required fields, maps the request to Afterpay JSON, calls the REST API, stores the checkout reference, and returns the token or redirect information. Validation failures are rejected immediately and transient API failures use bounded retry logic.

Martini capabilities used
  • APIs
  • workflows
  • API consumption
  • data mapping
  • business rules
  • error handling

Pattern 2: Capture payments after fulfillment

When to use this pattern

Use this pattern when an order-management or warehouse process marks an Afterpay order ready for fulfillment and the merchant is permitted to capture the authorization. The pattern prevents fulfillment status and payment state from drifting apart.

Integration direction
NetSuite
Martini
Afterpay
Example Mapping
Afterpay FieldCanonical FieldTarget Field
afterpayPaymentReferencepaymentReferencepaymentReference
fulfilledOrder.totalcaptureAmountamount
orderNumbermerchantOrderIdorderNumber
fulfillmentStatuscaptureEligibilitycaptureRule
Martini implementation pattern

Martini receives the fulfillment event, retrieves the durable payment reference, checks local operation history and current status where possible, validates the capture amount, and submits the capture. The response is written back to the order and finance systems. A retry never repeats a financial action without checking whether the original request was accepted.

Martini capabilities used
  • event-driven workflows
  • API consumption
  • validation
  • business rules
  • idempotency controls
  • error handling

Pattern 3: Synchronize Afterpay refunds

When to use this pattern

Use this pattern when commerce, ERP, or customer-service users initiate full or partial refunds. The workflow ensures that the requested refund does not exceed the captured amount less earlier refunds and that downstream systems receive the Afterpay result.

Integration direction
Shopify
Martini
Afterpay
Example Mapping
Afterpay FieldCanonical FieldTarget Field
orderNumbermerchantOrderIdorderNumber
refund.amountrefundAmountamount
refund.reasonrefundReasonreason
afterpayPaymentReferencepaymentReferencepaymentReference
Martini implementation pattern

Martini validates the refund against locally recorded captures and prior refunds, checks for an existing operation key, maps the request to Afterpay, and updates the originating order and finance records. Permanent validation or business-state errors are routed to an exception process; uncertain outcomes are reconciled before retrying.

Martini capabilities used
  • workflows
  • data mapping
  • financial validation
  • business rules
  • error handling
  • scheduled reconciliation

Pattern 4: Process callbacks and reconcile payment status

When to use this pattern

Use this pattern when selected Afterpay status notifications are enabled but the merchant requires a control for missed callbacks, duplicates, and state mismatches. It combines near-real-time updates with scheduled status checks.

Integration direction
Afterpay
Martini
Salesforce
Example Mapping
Afterpay FieldCanonical FieldTarget Field
paymentReferenceexternalPaymentIdAfterpay Payment ID
orderReferenceexternalOrderIdOrder Number
paymentStatepaymentStatusPayment Status
eventTimestampstatusUpdatedAtLast Payment Update
Martini implementation pattern

Martini exposes an authenticated callback API and starts a workflow that validates, correlates, deduplicates, and updates downstream systems. A scheduler later checks unresolved or recently changed transactions through individual Afterpay status requests, persists checkpoints, and sends mismatches to exception handling.

Martini capabilities used
  • APIs
  • webhook consumption
  • start triggers
  • workflow orchestration
  • scheduled workflows
  • deduplication
  • monitoring

Applications commonly integrated with Afterpay

Afterpay is typically connected to commerce, order, finance, and customer-service applications so payment actions and status changes remain aligned across the transaction lifecycle. Martini can centralize the API orchestration, mapping, validation, reconciliation, and exception handling between these products.

Application Scenario Direction Martini Pattern
Shopify Add Afterpay as a checkout and payment option while synchronizing order, capture, refund, and payment status information. Shopify → Martini → Afterpay Martini exposes or consumes the commerce workflow, maps Shopify order and customer data into an Afterpay Checkout request, calls the REST API, and routes status notifications or reconciliation results back to Shopify.
Adobe Commerce Support Afterpay checkout, capture after fulfillment, and full or partial refunds in a commerce platform. Adobe Commerce → Martini → Afterpay A Martini workflow validates totals and currency, creates the Afterpay Checkout, stores references, and orchestrates capture and refund operations with bounded retries and duplicate-action protection.
BigCommerce Keep checkout, order, payment, capture, and refund states aligned with Afterpay. BigCommerce → Martini → Afterpay Martini transforms BigCommerce order data into Afterpay JSON, stores the Afterpay order or payment reference, and uses callbacks plus scheduled status checks to update the commerce process.
Salesforce Commerce Cloud Centralize Afterpay payment orchestration and reconciliation within a larger digital-commerce estate. Salesforce Commerce Cloud → Martini → Afterpay Martini provides an API-led abstraction for checkout and payment actions, isolates Afterpay credentials, and maps regional commerce fields to Afterpay’s checkout, order, and payment structures.
NetSuite Post orders, payment states, captures, refunds, and related financial information into ERP and finance processes. Afterpay → Martini → NetSuite Martini consumes Afterpay responses and status notifications, normalizes amounts and references, and writes them to NetSuite while allowing approved refund or adjustment requests to flow back through Afterpay.
Salesforce Give customer-service teams visibility into Afterpay payment, order, and refund status. Afterpay → Martini → Salesforce Martini correlates Afterpay payment or order references with customer and order data, applies field-level transformations, and updates Salesforce from callbacks or reconciliation workflows.
Shopify Plus Orchestrate Afterpay checkout, fulfillment capture, refunds, and multi-system reconciliation for larger merchants. Shopify Plus → Martini → Afterpay Martini separates checkout, fulfillment, and refund workflows, applies business rules for financial operations, and records durable operation keys before calling Afterpay.

How to build a Afterpay integration in Martini

Objective

Configure the Afterpay sandbox or production base URL and merchant credentials without placing secrets in workflow definitions or client-side code.

Instructions in Martini

  • Create separate environment configuration for sandbox and production
  • Store the merchant ID and secret key in Martini Secrets Management
  • Configure HTTPS REST authentication using Afterpay’s merchant credentials
  • Restrict logging and responses so the secret key is never exposed

Objective

Select the event, API request, or schedule that starts each payment workflow.

Instructions in Martini

  • Use an inbound Martini API for checkout, capture, or refund requests
  • Use a callback endpoint for supported Afterpay status notifications
  • Use a scheduler for reconciliation of outstanding transactions
  • Use a start trigger to route inbound events into the appropriate workflow

Objective

Obtain the current Afterpay checkout, order, payment, or refund information needed for the business operation.

Instructions in Martini

  • Receive and validate the upstream commerce or ERP request
  • Call the relevant Afterpay REST endpoint when current status is required
  • Process callbacks as notifications rather than assuming complete event coverage
  • Persist references and reconciliation checkpoints

Objective

Coordinate validation, API calls, state checks, downstream updates, and exception paths in a maintainable Martini workflow.

Instructions in Martini

  • Separate checkout, capture, void, refund, and reconciliation logic
  • Check existing operation state before retrying financial actions
  • Route permanent business errors separately from transient service failures
  • Use reusable mappings and services for regional or product-specific differences

Objective

Convert internal commerce and finance models into Afterpay JSON and normalize responses for downstream applications.

Instructions in Martini

  • Map order, consumer, item, shipping, amount, currency, and redirect fields
  • Use decimal-safe calculations for financial values
  • Normalize Afterpay references, statuses, timestamps, and response identifiers
  • Limit consumer data and mask sensitive values in logs

Objective

Protect payment integrity by enforcing amount, currency, state, authorization, and duplicate-operation rules before calling Afterpay.

Instructions in Martini

  • Validate that totals reconcile across items, tax, shipping, discounts, and currency
  • Confirm capture and refund eligibility from local state and merchant permissions
  • Use stable order or operation references for correlation
  • Treat duplicate callbacks as expected input

Common Afterpay data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
CheckoutPayment-session request containing order details, consumer information, redirect URLs, and an Afterpay token or checkout reference.Shopify, Adobe Commerce, BigCommerce, Salesforce Commerce CloudMartini validates totals, currency, redirects, and required fields, then maps the internal commerce model into an Afterpay Checkout JSON request.
OrderMerchant purchase submitted for Afterpay financing, including order number, amount, currency, items, shipping, and consumer details.Commerce platforms, NetSuite, SalesforceMartini normalizes order identifiers, amounts, addresses, and line items and preserves the Afterpay reference for correlation and reconciliation.
PaymentAuthorization, capture, void, and payment-state information associated with an Afterpay order.Order management, NetSuite, Salesforce, commerce platformsMartini orchestrates permitted payment operations, checks current state before retries, and records operation results and references.
RefundFull or partial amount returned against a captured Afterpay payment.Commerce platforms, NetSuite, customer-service applicationsMartini validates the refund against captured and previously refunded amounts, submits the request, and synchronizes the response downstream.
ConsumerCustomer name, email, phone, billing, and shipping information supplied during checkout.Commerce platforms, Salesforce, order-management systemsMartini maps only required consumer fields, limits sensitive logging, and applies organization-specific data retention and masking rules.

Authentication and security considerations

Merchant authentication

Afterpay’s online APIs use merchant-specific credentials with HTTP Basic Authentication. The merchant ID is the username and the secret key is the password. OAuth 2.0 bearer authentication was not confirmed for this API.

Credential protection

  • Store the merchant ID and secret key in Martini Secrets Management.
  • Keep sandbox and production credentials and base URLs separate.
  • Use HTTPS for every request.
  • Do not expose secret keys in responses, mappings, logs, or client-side code.

Callback protection

For Afterpay callbacks, configure the authentication or signature validation required by the applicable account and region. Validate payloads, correlate references, and record identifiers needed for deduplication.

Personal data

Checkout data can include names, addresses, email addresses, phone numbers, and order details. Limit body logging, mask personal data where possible, and retain only the information required by the integration.

Operational considerations for Afterpay integrations

Financial accuracy

Use decimal-safe calculations and confirm that item totals, tax, shipping, discounts, currency, and order totals reconcile before creating checkouts, captures, or refunds.

Retries and idempotency

Use bounded retries with backoff for transient failures. Do not automatically repeat capture or refund requests without checking the original outcome. Store stable operation references and treat duplicate callbacks as expected input.

Regional configuration

Confirm the applicable country, currency, API base URL, API version, merchant permissions, and sandbox or production behavior. Request and response fields may vary by region, version, and product configuration.

Reconciliation

Because no general-purpose bulk API was confirmed, process individual status requests in bounded scheduled batches. Persist checkpoints and compare order references, payment references, amounts, currency, state, timestamps, and synchronization results.

Schema and monitoring

Isolate Afterpay mappings in reusable assets and monitor changes to checkout, consumer, payment, refund, and callback structures. Classify failures, retain actionable logs without credentials or unnecessary personal data, and route unresolved financial states to exception handling.

Why use Martini instead of scripts or point-to-point integrations?

Centralized orchestration

Martini provides a controlled integration layer between Afterpay and commerce, order, ERP, finance, and customer-service applications. This avoids duplicating payment logic across point-to-point implementations.

Reusable API-led integration

Martini can expose an internal payment API that hides Afterpay credentials and vendor-specific payloads from upstream applications while preserving a reusable workflow design.

Reliable data handling

Workflows can validate financial data, transform JSON structures, apply business rules, manage callback and reconciliation paths, and distinguish retryable failures from permanent payment-state errors.

Maintainability

Reusable mappings, environment-specific secrets, scheduled workflows, monitoring, and explicit exception handling make regional configuration and Afterpay API changes easier to manage than isolated scripts.

Frequently asked questions

How can Afterpay be integrated with enterprise systems?

Afterpay can be integrated through its HTTPS REST APIs using JSON and merchant credentials with HTTP Basic Authentication. Typical flows create checkouts, retrieve payment or order status, capture or void authorizations, and submit full or partial refunds. Selected payment lifecycle notifications may also be delivered through configured callbacks, with scheduled API reconciliation used as a complementary control.

Can Martini integrate with Afterpay?

Yes. Martini can consume Afterpay REST APIs, expose an internal API for commerce or ERP applications, map order and consumer data into Afterpay JSON, receive selected Afterpay callbacks where enabled, and run scheduled reconciliation workflows.

Do I need a connector to integrate Afterpay with Martini?

No. A dedicated Afterpay connector is not required. Martini can integrate using Afterpay’s confirmed native REST APIs, HTTP Basic Authentication, JSON payloads, and selected callback or notification endpoints.

Is there any extra Lonti cost to integrate Afterpay with Martini?

Lonti does not charge an additional per-connector or per-vendor fee to integrate Afterpay. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Afterpay, cloud infrastructure, or other third-party systems based on subscription, usage, and deployment model.

Which Afterpay integration methods should be used?

The primary method is the Afterpay Online REST API over HTTPS with JSON. It supports checkout and payment lifecycle operations, including capture, void, status retrieval, and refunds. Callback or webhook-style notifications are secondary and limited to selected events, products, regions, or configurations. No public GraphQL or SOAP API was confirmed.

Can Afterpay send payment events to Martini?

Afterpay supports callback or webhook-style notifications for selected payment lifecycle events where enabled. Coverage, authentication or signing requirements, retry behavior, and regional availability must be confirmed for the merchant. Martini can receive these notifications through an API and use scheduled reconciliation to identify missed or unresolved updates.

How does synchronization between Afterpay and other systems work?

Martini can synchronize checkout, order, payment, consumer, and refund information through API-led workflows. It correlates the merchant order number and Afterpay references, maps statuses and financial amounts, processes callbacks when available, and periodically retrieves individual statuses for outstanding transactions because a general-purpose bulk API was not confirmed.

How does Martini handle Afterpay errors, retries, and duplicate financial actions?

Martini can classify authentication, validation, business-state, network, and rate-limit failures, using bounded backoff retries only for appropriate transient errors. Before retrying capture or refund operations, the workflow checks whether the original request succeeded and uses durable operation references or local idempotency records to prevent duplicate financial actions.