Zip is a global buy-now-pay-later (BNPL) and payments fintech platform that lets merchants offer flexible installment payments at checkout. Its merchant API provides access to core payment workflows — creating and capturing charges, managing checkout sessions, processing refunds and voids, and handling disputes and settlement reconciliation. Merchants integrate it to boost conversion and average order value.
Power end-to-end data operations for your Zip API with Nexla. Our bi-directional Zip connector is purpose-built for Zip, making it simple to ingest data, sync it across systems, and deliver it anywhere — all with no coding required. Nexla turns API-sourced data into ready-to-use, reusable data products and makes it easy to send data to Zip or any other destination. With comprehensive monitoring, lineage tracking, and access controls, Nexla keeps your Zip workflows fast, secure, and fully governed.
Features
Type: API
SourceDestination
Seamless API Integration: Connect to any endpoint as source or destination without coding, with automatic data product creation
Visual Composition & Chaining: Build complex integrations using visual templates, chain API calls, and compose workflows with data validation and filtering
API Proxy: Expose curated slices of your data securely with a secure and customizable API proxy that validates and transforms data on the fly
Request optimization with intelligent batching, retry, and caching to minimize API calls and costs
Zip uses API key authentication for its merchant API. Your API key is a secure credential that identifies and authorizes your merchant account for all API requests. Before creating a Zip credential in Nexla, ensure you have access to your Zip Merchant Dashboard and have obtained your API key.
Zip API keys are tied to your merchant account and environment (sandbox or production). You will need separate keys for sandbox testing and production use.
Log in to your Zip Merchant Dashboard as an admin user. API keys are only accessible to admin-level accounts for security reasons.
Navigate to Settings > Integrations in the left-hand menu.
Locate the API Keys section. You may see two sets of keys — one for Sandbox (testing) and one for Production (live transactions).
Copy the API key for the environment you intend to use.
Keep your API key confidential. Do not place it in publicly accessible locations such as open-source repositories or client-side code. For additional details, see the Zip Authentication documentation.
After selecting the data source/destination type, click the Add Credential tile to open the Add New Credential overlay.
Enter a name for the credential in the Credential Name field and a short, meaningful description in the Credential Description field.
Enter your Zip Merchant API key in the API Key field. This is the key obtained from your Zip Merchant Dashboard under Settings > Integrations. Zip authenticates API requests using a Bearer token scheme — Nexla automatically formats this key as Bearer {your_api_key} in the Authorization header for all Zip API requests.
The API key is transmitted securely and stored encrypted in Nexla.
Select or enter the Base URL for your Zip environment:
Select Production (https://merchant-api.zip.co) for live merchant transactions.
Select Sandbox (https://sand.merchant-api.com) for testing and development.
You may also enter a custom base URL if your Zip account uses a different regional endpoint.
Click the Save button at the bottom of the overlay. The newly added credential will now appear in a tile on the Authenticate screen during data source/destination creation.
To create a new data flow, navigate to the Integrate section, and click the New Data Flow button. Select the Zip connector tile, then select the credential that will be used to connect to the Zip instance, and click Next; or, create a new Zip credential for use in this flow.
Nexla provides pre-built templates that can be used to rapidly configure data sources to ingest data from common Zip API endpoints. Select the endpoint from which this source will fetch data from the Endpoint pulldown menu. Available endpoint templates are listed in the expandable boxes below.
Get Charge
Retrieves the details of a single charge by its unique identifier. Use this endpoint when you need to look up the status, amount, or metadata of a specific Zip charge — for example, to verify whether a payment was successfully captured or to audit a particular transaction.
Enter the unique identifier of the charge you want to retrieve in the Charge ID field. Charge IDs are returned by Zip when a charge is created and can also be found in your Zip Merchant Dashboard under the Orders or Transactions section.
This endpoint retrieves a single charge record. The response includes charge status, amount, currency, associated checkout ID, and timestamps.
The Charge ID is a required field for this endpoint. For retrieving a list of multiple charges with filtering options, use the List Charges endpoint instead.
List Charges
Retrieves a paginated list of charges associated with your merchant account. Use this endpoint for bulk data exports, reconciliation, reporting, or auditing charge activity across your Zip integration. Results are returned in pages of up to 50 records.
Optionally, enter a Merchant ID to filter charges to a specific merchant sub-account. Leave this field blank to retrieve charges for your primary merchant account.
Optionally, enter a From Date (in yyyy-MM-dd format) to filter charges created on or after this date. For example, enter 2025-01-01 to retrieve charges from January 1, 2025 onward.
Optionally, enter a To Date (in yyyy-MM-dd format) to filter charges created on or before this date. Use this in combination with From Date to define a specific date range.
Optionally, enter a Status value to filter charges by their current state. Common Zip charge statuses include:
authorised — Funds have been ring-fenced but not yet captured.
captured — Payment has been fully captured and funds transferred.
cancelled — The charge was voided before capture.
refunded — The charge has been partially or fully refunded.
All filter parameters are optional. When no filters are applied, this endpoint returns all charges for your account in reverse chronological order. Nexla automatically handles pagination to retrieve all matching records.
Get Checkout
Retrieves the details of a specific checkout session by its unique identifier. Use this endpoint to inspect the status and configuration of a checkout — for example, to verify whether a customer completed a checkout flow or to retrieve the checkout data needed to initiate a charge.
Enter the unique identifier of the checkout session you want to retrieve in the Checkout ID field. Checkout IDs are returned by Zip when a checkout is created via the Create Checkout endpoint.
The response includes checkout status, order details, consumer information, and any associated charge data. A checkout session must be completed by the customer before a charge can be created against it.
Checkout sessions in Zip have a limited validity window. Once a checkout session expires, a new one must be created. Refer to the Zip developer documentation for current session expiry details.
Get Dispute
Retrieves the full details of a single dispute record by its unique identifier. Use this endpoint to check the status and evidence of a specific chargeback or customer dispute — for example, to confirm whether a dispute is still open or has been resolved.
Enter the unique identifier of the dispute you want to retrieve in the Dispute ID field. Dispute IDs are assigned by Zip when a dispute is raised and can be found in your Merchant Dashboard or via the Search Merchant Disputes endpoint.
The response includes the dispute status, associated charge, reason code, evidence submitted, and relevant dates. Dispute statuses include states such as Open, Under Review, and Closed.
For searching disputes across a date range or filtering by status, use the Search Merchant Disputes endpoint instead.
Search Merchant Disputes
Searches for disputes associated with your merchant account within a specified date range. Use this endpoint for bulk dispute reporting, reconciliation workflows, or to monitor dispute trends over a given period. Results are paginated with up to 10 records per page.
Optionally, enter a Merchant ID to scope the search to a specific merchant sub-account. Leave blank to search across your primary merchant account.
Optionally, enter a Start Date to define the beginning of the search date range. Dates should be in yyyy-MM-dd format (for example, 2025-01-01).
Optionally, enter an End Date to define the end of the search date range. Use this together with Start Date to narrow results to a specific period.
Optionally, enter a Status to filter disputes by their current state. Common Zip dispute statuses include:
Open — The dispute has been raised and is awaiting merchant response.
Under Review — Evidence has been submitted and the dispute is being reviewed.
Closed — The dispute has been resolved.
All filter parameters are optional. Nexla automatically handles pagination to retrieve all matching dispute records across multiple pages. For complete details, refer to the Zip disputes search documentation.
Get Settlement Invoices
Retrieves a paginated list of settlement invoices for reconciliation purposes. Use this endpoint to retrieve the invoices that Zip issues when it pays out merchant funds, which is essential for accounting, financial reporting, and payment reconciliation workflows. Results are returned in pages of up to 50 records.
This endpoint does not require any additional configuration parameters beyond selecting it from the Endpoint pulldown menu.
The response includes invoice identifiers, settlement amounts, associated transaction periods, and payout dates. Each invoice corresponds to a settlement batch from Zip to your merchant account.
Settlement invoices represent funds that Zip has paid out to your bank account. Use this endpoint alongside Get Settlement Transactions to perform a complete settlement reconciliation. For additional details, see the Zip settlements invoices documentation.
Get Settlement Transactions
Retrieves a paginated list of individual transactions included in settlement reports. Use this endpoint to obtain the line-item transaction data that makes up each settlement batch — essential for detailed financial reconciliation, revenue recognition, and auditing. Results are returned in pages of up to 50 records.
This endpoint does not require any additional configuration parameters beyond selecting it from the Endpoint pulldown menu.
The response includes transaction-level details such as transaction IDs, charge references, transaction types (sale, refund, dispute), amounts, and settlement dates.
Use this endpoint alongside Get Settlement Invoices for complete settlement reconciliation — invoices provide the summary-level payout data, while settlement transactions provide the underlying line items. For additional details, see the Zip settlements report documentation.
Once the selected endpoint template has been configured, click the Test button to the right of the endpoint selection menu to retrieve a sample of the data that will be fetched. Sample data will be displayed in the Endpoint Test Result panel on the right, allowing you to verify that the source is configured correctly before saving.
Zip data sources can also be manually configured to ingest data from any valid Zip API endpoint, including endpoints not covered by the pre-built templates, chained API calls, or custom request parameters. Select the Advanced tab at the top of the configuration screen, and follow the instructions in Connect to Any API to configure the API method, endpoint URL, date/time and lookup macros, path to data, metadata, and request headers.
Zip API endpoint URLs follow this pattern: https://merchant-api.zip.co/global/v1/{resource} for production or https://sand.merchant-api.com/global/v1/{resource} for sandbox — for example, https://merchant-api.zip.co/global/v1/charges to retrieve all charges. Paginated responses (such as List Charges) wrap records in a data array, so set the path to data to $.data[*].
The Zip API requires a QP-Territory header to specify the region for the API call (e.g., QP-Territory:AU). You do not need to include the Authorization header — Nexla adds this automatically from your configured credential — but QP-Territory must be added manually as a request header.
Once all of the relevant settings have been configured, click the Create button in the upper right corner of the screen to save and create the new Zip data source. Nexla will now begin ingesting data from the configured endpoint and will organize any data that it finds into one or more Nexsets.
Click the + icon on the Nexset that will be sent to the Zip destination, and select the Send to Destination option from the menu. Select the Zip connector from the list of available destination connectors, then select the credential that will be used to connect to the Zip organization, and click Next; or, create a new Zip credential for use in this flow.
Nexla provides pre-built templates that can be used to rapidly configure destinations to send data to common Zip API endpoints. Select the endpoint to which data will be sent from the Endpoint pulldown menu. Then, click on the template in the list below to expand it, and follow the instructions to configure additional endpoint settings.
Create Charge
Creates or captures a charge on an existing, approved checkout session. Use this endpoint to complete a payment after a customer has successfully completed the Zip checkout flow. This is the final step to confirm a purchase and transfer funds.
This endpoint requires no additional parameter configuration beyond selecting it from the Endpoint pulldown menu. The request body containing charge details (such as the checkout token and capture flag) is taken from the Nexset data being sent to this destination.
The Nexset data sent to this endpoint should include the following fields:
checkoutId or token — The identifier of the approved Zip checkout session to charge.
capture — Set to true to immediately capture funds, or false to authorize only (ring-fence funds for later capture).
A charge must be created within the validity window of the checkout session — if the checkout expires before a charge is created, a new checkout session must be initiated. For full request body details, refer to the Zip developer documentation.
Capture Charge
Captures an existing authorized charge, completing the payment and transferring funds from the customer to the merchant. Use this endpoint when a charge was previously created with capture: false (authorization only) and you are now ready to finalize the transaction — for example, when fulfilling a delayed shipment or confirming a booking.
Enter the unique identifier of the authorized charge to capture in the Charge ID field. This is the charge ID returned by Zip when the original charge was created.
The request body sent to this endpoint can include an optional amount to perform a partial capture. If no amount is specified, the full authorized amount will be captured.
Capturing a charge is a one-time action — once captured, a charge cannot be un-captured. To cancel an authorized charge without capturing, use the Void Charge endpoint instead.
Refund Charge
Refunds an existing captured charge, returning funds to the customer. Use this endpoint to process customer refunds for completed Zip transactions — for example, for returned goods, cancelled orders, or service credits. Both full and partial refunds are supported.
Enter the unique identifier of the charge to refund in the Charge ID field. This is the charge ID of the previously captured transaction.
The Nexset data sent to this endpoint should include the refund details:
amount — The amount to refund, in the transaction currency. Omit this field or set it to the full charge amount for a complete refund.
reason — An optional description of the reason for the refund.
Refunds processed via the Zip API are typically reflected in the customer's account within a few business days. Zip applies a negative transaction to the settlement reconciliation for the refunded amount.
Void Charge
Voids (cancels) an existing authorized charge before it has been captured. Use this endpoint to release ring-fenced funds back to the customer when an order needs to be cancelled after authorization but before payment capture — for example, when an item is out of stock or a booking is cancelled.
Enter the unique identifier of the authorized charge to void in the Charge ID field. Only charges that have been authorized but not yet captured can be voided.
No additional request body parameters are required for a void operation.
A void can only be performed on an authorized charge that has not yet been captured. If a charge has already been captured and you need to return funds to the customer, use the Refund Charge endpoint instead.
Create Checkout
Creates a new Zip checkout session for a merchant. Use this endpoint to initiate the Zip payment flow for a customer — the checkout session captures order details and returns a redirect URL or token that the customer uses to complete their Zip payment. This is the first step in the Zip charge lifecycle.
This endpoint requires no additional parameter configuration beyond selecting it from the Endpoint pulldown menu. All checkout details — including order amount, currency, items, and consumer information — are provided in the Nexset data sent as the request body.
The Nexset data sent to this endpoint should include the core checkout fields:
amount — The total order amount.
currency — The ISO 4217 currency code (e.g., AUD, USD).
order — Order details including reference, items, and shipping information.
consumer — Customer details including name and email address.
config.redirect_uri — The URL Zip will redirect the customer to after completing the checkout.
The response from this endpoint includes a uri field containing the Zip-hosted checkout URL that you should redirect the customer to. After the customer completes the checkout, use the Create Charge endpoint to finalize the payment.
Accept Dispute and Close
Closes a dispute by accepting the loss, finalizing the dispute resolution without contesting the chargeback. Use this endpoint when you choose not to submit evidence for a dispute and want to accept the outcome — for example, when the customer's claim is valid, or when the cost of contesting is not justified.
This endpoint requires no additional parameter configuration beyond selecting it from the Endpoint pulldown menu. The dispute identifier and any required closure details are provided in the Nexset data sent as the request body.
Once accepted and closed, a dispute cannot be re-opened. The associated chargeback amount will be deducted from your next settlement.
Accepting a dispute is irreversible. If you wish to contest a dispute instead, use the Submit Dispute Evidence endpoint before the evidence submission deadline. For more information, see the Zip dispute close documentation.
Submit Dispute Evidence
Submits evidence to contest a dispute. Use this endpoint when you want to challenge a chargeback by providing supporting documentation such as proof of delivery, refund policies, or records showing the transaction was legitimate. Evidence submissions are final and cannot be modified after submission.
This endpoint requires no additional parameter configuration beyond selecting it from the Endpoint pulldown menu. All evidence details are provided in the Nexset data sent as the request body.
The Nexset data sent to this endpoint should include the dispute identifier and the relevant evidence. Types of evidence that Zip accepts include:
Refund policy — Documentation of your store's refund or return policy.
Cancellation policy — Documentation of your cancellation policy if applicable.
Proof of delivery — Shipping tracking records or delivery confirmation.
Duplicate charge documentation — Evidence that the disputed transaction is not a duplicate.
Important
Evidence submissions are final and cannot be modified or withdrawn after submission. Ensure all evidence is accurate and complete before sending. For details on accepted evidence formats, refer to the Zip submit evidence documentation.
Once the selected endpoint template has been configured, click the Test button at the top of the Sample Payload panel to send a test payload to the Zip API using the current settings, and verify the destination is configured correctly.
Zip destinations can also be manually configured to send data to any valid Zip API endpoint. Select the Advanced tab at the top of the configuration screen, and follow the instructions in Connect to Any API to configure the API method, data format, endpoint URL, request headers, attribute exclusions, record batching, and response webhooks.
Zip API endpoint URLs follow this pattern: https://merchant-api.zip.co/global/v1/{resource} for production — for example, https://merchant-api.zip.co/global/v1/checkouts to create a checkout, or https://merchant-api.zip.co/global/v1/charges/{charge_id}/capture to capture a specific charge. The Zip API accepts JSON format for all request bodies.
The Zip API requires a QP-Territory header to specify the region for the API call (e.g., QP-Territory:AU). You do not need to include the Authorization header — Nexla adds this automatically from your configured credential — but QP-Territory must be added manually as a request header. Most Zip API endpoints accept one operation per request, so record batching generally does not apply beyond custom bulk workflows.
Once all endpoint settings have been configured, click the Done button in the upper right corner of the screen to save and create the destination. To send the data to the configured Zip endpoint, open the destination resource menu, and select Activate.
The Nexset data will not be sent to the Zip API until the destination is activated. Destinations can be activated immediately or at a later time, providing full control over data movement.
