The following sections are general information required for using the Flute API suite.

# baseURL Environments

Flute provides different environments to run endpoints.


**Sandbox**
The sandbox environment is for development and testing.
No payments, charges, or invoices will be enforced.
It is a fully isolated account that mirrors production behavior.

It is used to validate your integration before going live.
You will work with your Flute support team developing workflows and tools.

baseURL: `https://sandbox.api.flute.com`

**Production**
The production environment is for deploying the payment system live to clients.
All payments, charges, or invoices are live and will be enforced.

When your product is ready to be deployed live, the Flute support team will work with you to ensure compliance.
This compliance follows the production readiness checklist.
It ensures the best and optimal developer, client, and customer experience.
For more information and details about the production readiness checklist, see Production Go-Live Guide.

baseURL: `https://api.flute.com`

**Using the baseURL**
Use the baseURL instead of the placeholder noted in each endpoint.
For example, an endpoint may be described in the endpoint documentation as:
`GET {{baseURL}}/v2/customers`

To make this call in the sandbox environment, use:
`POST https://sandbox.api.flute.com/v2/customers`

To make this call in the production environment, use:
`POST https://api.flute.com/v2/customers`

# Payment Flow

h1
The following is a generalized workflow.

## Approving a Purchase Request

1) The customer completes their shopping experience on the merchant's website by selecting the products or services.
They navigate to the checkout page on the merchant's website.
2) They enter their personal and payment information. This could include card details, or net banking information.
3) The merchant's website captures these details, formatting the details as needed to conform to Flute payment gateway requirements.
4) This sensitive data is transmitted by a secure connection (HTTPS) to the Flute payment gateway.
The Flute payment gateway is a service that makes authorization and sale by cards or ACH (automated clearing house, an electronic network used by financial institutions to process direct deposits).
5) Upon receiving this information, the Flute payment gateway further routes this payment data to the processing center, such as TSYS.
6) This entity communicates with the customer's bank to get authorization or denial for the payment.
The processing center determines if the payment is approved, that is, if there are sufficient funds or credit available in the customer's account.


## Acknowledging a Purchase Request

1) After the transaction is processed, the processing center sends back a response to the Flute payment gateway.
This response includes details of the transaction, such as whether it was approved or declined.
2) The Flute payment gateway relays this information back to the merchant's website.
3) The merchant's website receives this information and displays a message or signal for the customer.
Depending on whether the transaction was approved or declined, the appropriate message is displayed to the customer.
For instance:
  * If transaction was successful, a confirmation message is shown, usually with a transaction ID and other details.
  * If it was declined, the customer is informed and typically asked to try another payment method.


## Supported Card Types

h1
The following credit cards and formats are supported.

- Diners Club: Card numbers are typically 14 or 16 digits long.
- Discover: Card numbers are typically 16 digits long.
- JCB: Card numbers are typically 16 digits long.
- MasterCard: Card numbers are typically 16 digits long.
- VISA: Card numbers are typically 13 or 16 digits long.


# Flute-Defined Enums

h1
The following are Flute-defined enumerations and indices used in endpoint fields.

details
summary
Account Holder Types
| id | name |
|  --- | --- |
| 1 | Business |
| 2 | Personal |


details
summary
Account Types
| id | name |
|  --- | --- |
| 1 | Checking |
| 2 | Savings |


details
summary
Business Categories
| id | name |
|  --- | --- |
| 1 | WebDeveloper |
| 2 | IndependentSoftwareVendor |
| 3 | IndependentSalesOrganization |


details
summary
Credit Card Types
a
| id | name |
|  --- | --- |
| 1 | Visa |
| 2 | MasterCard |
| 3 | AmericanExpress |
| 4 | DinersClub |
| 5 | Discover |
| 6 | JCB |


details
summary
Transaction Creator Types
a
| id | name |
|  --- | --- |
| 1 | Portal |
| 2 | ApiToken |
| 3 | Terminal |
| 4 | Invoice |
| 5 | QuickPayment |
| 6 | WebComponent |
| 7 | Subscription |
| 8 | MobileApp |
| 9 | TapToPay |


details
summary
Partner Statuses
| id | name |
|  --- | --- |
| 1 | Active |
| 2 | Suspended |


details
summary
Partner Business Model Types
| id | name |
|  --- | --- |
| 1 | SingleAffiliateModel |
| 2 | SubAffiliateModel |


details
summary
Payment Method Types
| id | name |
|  --- | --- |
| 1 | Card |
| 2 | ElectronicCheck |


details
summary
Payment Processor Statuses
| id | name |
|  --- | --- |
| 1 | Active |
| 2 | Inactive |


details
summary
Payment Processor Types
| id | name |
|  --- | --- |
| 1 | TSYS |
| 2 | EFT |


details
summary
Payment Session Statuses
| id | name |
|  --- | --- |
| 1 | Created |
| 2 | Cancelled |
| 3 | Completed |
| 4 | Failed |


details
summary
Transaction Statuses
a
| Status Code | Status | Description | Available actions |
|  --- | --- | --- | --- |
| 1 | Authorized | Transaction status after an approved `pre-authorization` request | Capture, Void |
| 2 | Captured | Transaction status after approved `sale` or `capture` request | Void |
| 3 | Voided | Transaction status after merchant voids an `authorized` request or refunds a `captured` (not settled) request | N/A |
| 4 | Refunded | Transaction status after merchant refunds a `settled` request | N/A |
| 5 | Verified | NA | N/A |
| 6 | Settled | Transaction status after successful settlement request. All `captured` transactions should have status changed to `settled` | Refund |
| 7 | Partially Authorized | Transaction status after an approved `pre-authorization` request with the approved amount less than initially requested. Indicates that the issuer bank has approved only a portion of the requested payment amount. The exact authorized amount should be checked in the corresponding field. | Capture, Void |
| 8 | Informational | NA | N/A |
| 21 | Scheduled | NA | N/A |
| 24 | Pending | Transaction status while changing status. This is a temporary status | N/A |
| 91 | Declined | Transaction status after a denied `pre-authorization`, `sale` or `capture` request | N/A |
| 92 | Failed | Transaction status after a failure at any type of request | N/A |
| 92 | Expired | Transaction status after 7 days in `authorized` status (merchant has not captured within this time) | N/A |


details
summary
Transaction Types
a
| id | name |
|  --- | --- |
| 1 | Authorization |
| 2 | Sale |
| 3 | Capture |
| 4 | Void |
| 5 | Refund |
| 6 | CardAuthentication |
| 7 | RefundWORef |
| 8 | TipAdjustment |
| 11 | AchDebit |
| 12 | AchRefund |
| 13 | AchHold |
| 14 | AchUnHold |
| 15 | AchCancel |
| 16 | AchCredit |