The Finix API is resource oriented, relying heavily on common REST principles. Our API uses JSON encoded requests and responses.
You will receive separate Sandbox and Live accounts, as well as corresponding API credentials to access the Finix API.
The Finix API is resource oriented, relying heavily on common REST principles. Our API uses JSON encoded requests and responses.
You will receive separate Sandbox and Live accounts, as well as corresponding API credentials to access the Finix API.
To communicate with the Finix API, you must authenticate your requests via HTTP Basic Authentication with a username:password combination, which you can get from your Finix Dashboard. If you do not have a Dashboard yet, you can test our APIs with the Sandbox credentials below.
| Parameter | Value |
|---|---|
| Sandbox Username | USsRhsHYZGBPnQw8CByJyEQW |
| Sandbox Password | 8a14c2f9-d94b-4c72-8f5c-a62908e5b30e |
curl "https://finix.sandbox-payments-api.com/" \
-H "Content-Type: application/json" \
-H "Finix-Version: 2022-02-01" \
-u USsRhsHYZGBPnQw8CByJyEQW:8a14c2f9-d94b-4c72-8f5c-a62908e5b30eFinix provides two environments with distinct base URLs to make API requests.
These environments are entirely separate and do not share API Credentials.
| Environment | Endpoint URL |
|---|---|
| Sandbox | https://finix.sandbox-payments-api.com |
| Live | https://finix.live-payments-api.com |
To get access to the Live environment, please reach out to your Finix point-of-contact.
Finix uses HTTP codes to communicate whether requests succeeded or failed. Requests to Finix's API return responses within less than one second.
However, communications between card networks and processors can increase response latency. Additionally, response latency for card-present devices can be higher depending on how quickly buyers complete the transaction on payment terminals.
Due of this, requests to the Finix API have a maximum timeout of 5 minutes.
For more details, see Error Codes. Also, you can test for specific errors and responses.
| Code | Definition | Explanation |
|---|---|---|
400 | Bad Request | We could not parse your request. Verify you are providing valid JSON. |
401 | Unauthorized | We could not authenticate your request. Verify your username and password are correct. |
402 | Upstream Processor Error | Errors caused by 3rd-party service(s). |
403 | Forbidden | Your credentials do not have the correct permissions to perform the request. |
404 | Not Found | We could not find the specified resource. |
405 | Method Not Allowed | The specified resource does not support the HTTP Method used to submit the request. |
406 | Not Acceptable | The server could accept the submitted request. Confirm how the request was formatted and submitted. |
409 | Conflict | The submitted request conflicts with the current state of the server. |
422 | Unprocessable Entity | The parameters were valid, but the request failed. Usually, the error involves misunderstanding of how to perform the request (e.g., creating a transfer with a seller that is not-yet-approved). |
500 | Internal Server Error | We had a problem with our server. Try again later. |
The Authorization and Transfer resources both have an idempotency_id field. Use this field to ensure the API Request is performed only once.
Why is this important? We've all experienced a checkout page that hangs on a request or payment, and feared that if we refresh or submit the payment again, we'd be charged twice.
Finix removes this ambiguity with the idempotency_id. You or the user can generate a unique ID that can be included as an idempotency_id with the usual request payload. If anyone attempts a request with the same idempotency_id, the response will raise an exception.
By passing an idempotency_id in the body of your requests, you can be rest assured that when you create an Authorization or Transfer, the user will be protected from potential network issues.
idempotency_id is available on the following three endpoints:
/transfers/authorizations/transfers/{id}/reversalsidempotency_id checks against previous requests made on the same endpoint.
Every Finix resource (e.g., Authorizations, Transfers) can be listed and reviewed using GET requests. Additionally, every endpoint has query parameters available to help you filter the resources that are returned.
See the following example of how to query the Transfers endpoint for Transfer resources with type: DEBIT.
curl "https://finix.sandbox-payments-api.com/transfers?type=DEBIT" \
-H "Finix-Version: 2022-02-01" \
-u USsRhsHYZGBPnQw8CByJyEQW:8a14c2f9-d94b-4c72-8f5c-a62908e5b30eAs Finix improves our products and features, we will make changes to our APIs. When breaking changes are made to Finix's API, we may release a new dated API version.
The API version your requests use controls how API responses and webhooks behave (for example, the values you see in responses and the parameters you can include in requests). For more information, see Versioning.
To process payments, your Merchants must validate their compliance with PCI DSS requirements annually. To do this, your Merchants must attest to PCI Self-Assessment Questionnaire (SAQ) compliance forms.
Related Guides: Managing PCI Compliance, PCI DSS Compliance
A Device resource represents a Point-of-Sale terminal. Devices are used for In-Person transactions.
Disputes, also known as chargebacks, represent any customer-disputed charges. A core part of the dispute lifecycle is the ability for a Merchant to upload Dispute evidence that supports their side of the Dispute.
Related Guides: Managing Disputes
A fee_profiles represents a pricing scheme that automatically applies fees to each transaction. Changes to fee_profiles go into effect immediately.
Related Guides: Collecting Fees
Use Finix's File API to upload and manage files for your merchants.
Related Guides: File Uploads, Update Requests
An Identity resource represents either a person or business in Finix. You'll create an Identity to onboard your sellers, and verify the different owners.
Related Guides: Getting Started, Onboarding Sellers, Push to Card
With Finix's instrument_updates API, you can update the credit card information you have saved for customers without needing to contact each individual cardholder.
Related Guides: Account Updater
A Merchant resource represents the entity's merchant account on a processor. Your Merchant must be APPROVED to process payments.
Related Guides: Getting Started, Onboarding Sellers
Finix offers and hosts pre-built onboarding forms that you can use to collect onboarding and identity verification information from your users.
Related Guides: Onboarding, Onboarding Forms.
A Payment Instrument resource represents the payment details of a credit card or bank account. Payment details get tokenized multiple times and each tokenization produces a unique Payment Instrument.
A Payment Instrument is associated with a single Identity. Once a Payment Instrument is created, the Identity it's associated with can't be changed.
Including an address when creating a Payment Instrument can lower interchange on credit card transactions.
Related Guides: Using Hosted Fields, Getting Started
A Settlement is a logical construct representing a collection (i.e. batch) of Settlement Entries that will get paid out to a specific Merchant. A Settlement Entry can represent Transfers or Split Transfers
Related Guides: Payouts
A Settlement Queue Entry resource represents an entry in the settlement queue used to track when and how a transfer is queued to be processed.
If a merchant's settlement_queue_mode is set to MANUAL, all transfers will have a Settlement Queue Entry created and will not be placed into settlement until the Settlement Queue Entry is explicitly released using a PUT Update Settlement Queue Entries request.
Related Guides: Account Structures and Settlements
Transfers can be split among several different Merchants. A split_transfer represents how the funds from a split Transfer were distributed into a Merchants Settlement.
Related Guides: Online Payments Quickstart, Split a Transaction
A Transfer represents any flow of funds either to or from a Payment Instrument. All payments in Finix are represented by a Transfer.
Related Guides: Online Payments Quickstart, Level 2 and 3 Processing, POS Integration, Buyer Charges, ACH (eCheck) Direct Debit
A User resource represents a pair of API keys which are used to perform authenticated requests against the Finix API. When making authenticated requests via HTTP basic access authentication the ID of a User resource maps to the username, while the password corresponds to the password (i.e. secret key).
The password field for a User resource is only returned during the initial creation. Any following GET requests to the resource returns the password field as null for security purposes.
Related Guides: Account Structure
Creating an application user is the equivalent of provisioning API keys (i.e. credentials) for an Application.
Each Application can have multiple
Userswhich allows each seller to have multiple API keys that can be independently enabled and disabled. Merchants only have read access to the API.
curl "https://finix.sandbox-payments-api.com/applications/APc9vhYcPsRuTSpKD9KpMtPe/users" \
-u USfdccsr1Z5iVbXDyYt7hjZZ:313636f3-fac2-45a7-bff7-a334b93e7bda \
-H "Content-Type: application/json" \
-H "Finix-Version: 2022-02-01" \
-X POST \
-d '{}'Single User object.
ID of the Identity that the User object was created under.
Timestamp of when the user credentials were last used to make an API call.
Details the level of access the User has available.
Include up to 50 key: value pairs to annotate requests with custom metadata.
keys is 40.values is 500. (For example, order_number: 25, item_type: produce, department: sales){ "id": "USgYN9GjHUUvQ6gWed2bSX8E", "created_at": "2024-12-24T09:43:18.47Z", "updated_at": "2024-12-24T09:43:18.47Z", "created_by": "USfdccsr1Z5iVbXDyYt7hjZZ", "email": null, "enabled": true, "identity": "IDjvxGeXBLKH1V9YnWm1CS4n", "last_used_date": null, "password": "ff350382-5a5e-456d-be9f-78b1084358cf", "role": "ROLE_PARTNER", "tags": {}, "_links": { "self": { … }, "applications": { … }, "application": { … } } }
Retrieve a list of all Users.
For details on how to query endpoints using the available parameters, see Query Parameters.
curl "https://finix.sandbox-payments-api.com/users" \
-H "Finix-Version: 2022-02-01" \
-u USfdccsr1Z5iVbXDyYt7hjZZ:313636f3-fac2-45a7-bff7-a334b93e7bda{ "_embedded": { "users": [ … ] }, "_links": { "self": { … } }, "page": { "offset": 0, "limit": 20, "count": 6 } }
curl "https://finix.sandbox-payments-api.com/users/USfdccsr1Z5iVbXDyYt7hjZZ" \
-H "Finix-Version: 2022-02-01" \
-u USfdccsr1Z5iVbXDyYt7hjZZ:313636f3-fac2-45a7-bff7-a334b93e7bdaSingle User object.
ID of the Identity that the User object was created under.
Timestamp of when the user credentials were last used to make an API call.
Details the level of access the User has available.
Include up to 50 key: value pairs to annotate requests with custom metadata.
keys is 40.values is 500. (For example, order_number: 25, item_type: produce, department: sales){ "id": "USgYN9GjHUUvQ6gWed2bSX8E", "created_at": "2024-12-24T09:43:18.47Z", "updated_at": "2024-12-24T09:43:18.47Z", "created_by": "USfdccsr1Z5iVbXDyYt7hjZZ", "email": null, "enabled": true, "identity": "IDjvxGeXBLKH1V9YnWm1CS4n", "last_used_date": null, "password": "ff350382-5a5e-456d-be9f-78b1084358cf", "role": "ROLE_PARTNER", "tags": {}, "_links": { "self": { … }, "applications": { … }, "application": { … } } }
Webhooks lets you build or set up integrations which subscribe to certain automated notifications (i.e. events) on the Finix API. When one of those events is triggered, a HTTP POST payload is sent to the webhook's configured URL.
Related Guides: Webhooks
Checkout Forms are a low-code solution that enables you to create a customizable payment page where buyers can easily enter their payment details and submit a payment on both desktop and mobile devices.
With Checkout Forms, you can quickly create checkout pages and accept payments from buyers with minimal development work.
Related Guides: Checkout Pages
Payment Links create individual links you can send to buyers to complete a transaction. You can share these links on different platforms such as web pages, email, text, or QR codes.
Related Guides: Payment Links
A Payout Link is a unique, one-time link you can send via email or text to a recipient for fast and secure payouts. For card-based payouts, funds are typically available within minutes.
Payout Links can be used for various purposes, including insurance payments, sales commissions, and more. Each link can be customized to display your brand name and logo, providing a seamless experience for recipients.
Related Guides: Payout Links
The Receipt resource generates a receipt for Transfers or Authorizations. You can then send the Receipt via Email, SMS, or use the information from the Receipt to send it yourself.
Related Guides: Receipts for Online Payments
A Subscription resource represents a recurring charge to a Payment Instrument at regular intervals. Subscribers can be buyers, customers, or merchants.
When creating a Subscription, you have the option to use a Subscription Plan.
Limitations:
- Supported countries: At this time, subscriptions are available in the United States.
- Supported payment methods: Subscriptions currently support recurring card payments and recurring bank account payments (ACH in the USA).
- Approved merchants: At this time, only approved merchants with one of the following processors can create subscriptions: DUMMY_V1 and FINIX_V1.
Related Guides: Creating Subscriptions, Creating Subscription Plans, Recurring Payments Guidelines
A Subscription Plan resource is a template with set recurring costs and frequencies that can be reused across multiple Subscription resources.
Related Guides: Creating Subscriptions Plans, Creating Subscriptions, Recurring Payments Guidelines
A transfer_attempt is created when a buyer attempts to pay for a payment using a Payment Link or Checkout Form. Using Transfer Attempts, you can track the lifecycle of a payment or a series of payments if you are using a multi-use Payment Link.
Each transfer_attempt has as reference to a transfer_id to allow you to query it for additional data.
A Balance resource represents the current financial state of an Application identified by the linked_to query parameter.
It tracks the state of funds processed through the system, including amounts that are:
available_amount for immediate use or disbursement.pending_amount due to processing times, holds, or other constraints.posted_amount, which reflects the total sum (including both available and pending funds).The application_profile resource is used to configure the Application's Fee Profile. The Application's Fee Profile configures what Fee gets applied to transactions processed by the application_profile.
Related Guides: Onboarding Process, Collecting Fees
The Application resource represents your app. For example, an iOS app, website, online marketplace, SaaS platform, etc. – any web service that connects buyers (i.e. customers) and sellers (i.e. merchants). In other words, an Application is a resource that represents the program you're integrating with Finix and using to connect with customers (i.e. buyers).
Related Guides: Getting Started
Our Balance Transfers API provides platforms the option to create a money movement between their FBO (For the Benefit Of) Settlement account and their operating account. This is only available for Finix Core customers with Litle V12 credentials.
If you have any questions, please reach out to your Finix point of contact or contact the Finix Support team.
A merchant_profile links a merchant to it's risk_profile and fee_profile. Each merchant has a merchant_profile.
When a merchant gets created, a merchant_profile also gets created. This new merchant_profile automatically receives a new risk_profile and fee_profile that are copies of the risk and fee profiles on the application_profile.
Related Guides: Collecting Fees
A Payout Profile configures how fees and payouts get calculated and processed.
Related Guides: Configuring Payouts
Funds are released to sub-merchants when a Settlement's corresponding Review Queue Item is marked as ACCEPTED by a user with the appropriate role permissions.
Related Guides: Roles & Permissions
Verifications are used to verify Identities and Payment Instruments.
For Identities, a verification represents an attempt to onboard and underwrite an identity.
For Payment Instruments, a verification represents getting additional information from the card brands to verify a card is eligible for push to card.
Related Guides: Onboarding with the API, Push to Card