Onboarding is the process of setting up a business to accept and process electronic payments.
The following is the application process.
A partner invites the merchant by creating a merchant application. The application collects the business's legal, ownership, banking, and processing information. The partner pre-fills any fields it already knows.
To create the application, see POST /v2/applications.
The application is attributed to a partner user. To find the partner user, see GET /v2/users with userType=Partner.
A Schedule A is the pricing schedule for the merchant. The partner assigns a Schedule A to the application. The Schedule A is sent in the scheduleAId field.
For more information, see Schedule A.
To list the partner user's Schedule As, see GET /v2/users/{userId}/schedule-as.
The split profile defines how residuals are shared. The partner assigns a split profile to the application. The split profile is sent in the splitProfileId field.
For more information, see Split Profiles.
To list the partner user's split profiles, see GET /v2/users/{userId}/split-profiles.
Application invitations are called onboarding invitations. The application, which includes the application form, the Schedule A, and the split profile, is sent to the merchant. The application link reaches the merchant by email.
Email delivery is set with "deliveryMethod": "Email" in POST /v2/applications.
The merchant completes the rest of the application. The merchant signs the merchant processing agreement and submits it.
To check the application status, see GET /v2/applications.
Flute reviews the application. Flute may ask the merchant for additional information or documents. Flute then approves or declines the application. The decision is based on the business's qualification for payment-processing services.
To check the application status, see GET /v2/applications.
If the application is approved, Flute sets up the merchant with the payment processor. The merchant is assigned an MID (the processor's merchant ID). The merchant is also assigned a merchantId for the Flute payment API.
Both values are returned by GET /v2/applications.
The merchant can start processing payments.
To find active merchants, see GET /v2/applications with applicationStatus=Active.
A Schedule A is a predefined pricing schedule that determines the pricing arrangement assigned to a merchant application.
It appears as an attachment to an agreement. However, Schedule A is not a standardized payment-industry term. Its meaning depends on the particular Flute agreement or document.
The agreement may be a merchant agreement, a partner agreement, or a payment-processing contract.
A merchant agreement and a payment-processing contract are not necessarily separate documents. In many payment-processing arrangements, the merchant agreement itself contains the payment-processing terms.
A partner agreement, however, generally governs a different relationship: the one between Flute and its business partner.
A merchant agreement establishes the contractual relationship between a merchant and the company or financial institution providing payment-processing services.
It typically defines:
- Payment acceptance: Which payment methods the merchant can accept, such as credit cards, debit cards, and ACH.
- Processing fees: What the merchant pays for processing transactions.
- Settlement: How and when transaction funds are deposited into the merchant's bank account.
- Chargebacks and refunds: The merchant's financial responsibilities when payments are disputed or refunded.
- Compliance: Requirements involving PCI DSS, card-network rules, and applicable laws.
- Termination: Conditions under which payment-processing services can be suspended or terminated.
A restaurant signs a merchant agreement to accept Visa and Mastercard payments through Flute. The agreement typically specifies the merchant's processing rates and applicable fees.
A partner agreement establishes the business relationship between Flute and a company that refers, manages, or integrates merchants into Flute's payment-processing platform. A partner might be an independent sales organization (ISO), independent software vendor (ISV), reseller, or another payments business.
It typically defines:
- Merchant acquisition: Whether the partner can refer or onboard merchants.
- Revenue sharing: How the partner earns commissions, residuals, or other compensation.
- Responsibilities: Which organization handles onboarding, support, compliance, and account management.
- API access: Whether the partner can integrate applications using Flute APIs.
- Merchant management: What the partner can configure or manage for its merchants.
- Termination: What happens to merchants and compensation when the partnership ends.
A point-of-sale software company partners with Flute to offer integrated payment processing to its restaurant customers. A partner may be authorized to assign particular Schedule A pricing schedules to merchant applications. This is consistent with Flute's GET /v2/users/{userId}/schedule-as endpoint.
A payment-processing contract establishes the legal and operational terms for processing, authorizing, clearing, and settling electronic payments. It typically defines:
- Authorization: How transactions are submitted for approval.
- Processing services: Which payment-processing functions are provided.
- Settlement and funding: How funds move between the processor, acquiring bank, and merchant.
- Risk management: Fraud controls, reserves, and financial liability.
- Service availability: Processing obligations and any applicable service commitments.
- Network compliance: Responsibilities under card-network and regulatory requirements.
A merchant's payment-processing contract establishes the terms. This includes which card transactions are processed and settled through an acquiring bank and processor. It may also define the processing fees and charges associated with those services.
To see the available Schedule As, use:
GET /v2/users/{userId}/schedule-as
This retrieves the pricing schedules available to a particular partner user. When creating a merchant application, the partner supplies the selected schedule's ID as scheduleAId. A Schedule A may be associated with a specific payment processor or apply to any processor. The API specification confirms the schedule assignment and processor association. It does not detail the individual fees or rates contained in each schedule.
Each Schedule A has the following properties.
| Field | Meaning |
|---|---|
| id | Unique identifier for the pricing schedule. |
| name | Schedule name displayed in the dashboard, such as Processor Name. |
| processorId | Payment processor associated with the schedule. A null value means the schedule can apply to any processor. |
A split profile is a predefined configuration associated with a merchant application that governs how residual compensation is allocated.
In payment processing, residuals refer to ongoing revenue earned by partners, ISOs, or sales representatives from merchants they bring onto the platform. A split profile determines how residual revenue is distributed among eligible parties.
For example, suppose a merchant generates $1,000 in residual revenue in a month. A hypothetical split profile could distribute it as follows:
| Recipient | Percentage | Amount |
|---|---|---|
| Partner | 60% | $600 |
| Sales representative | 30% | $300 |
| Other participant | 10% | $100 |
| Total | 100% | $1,000 |
Flute's v2 API defines a split profile as a residual configuration that a partner user can assign to a merchant application.
To see the available split profiles, use:
GET /v2/users/{userId}/split-profiles
This retrieves the split profiles available to a particular partner user. The selected profile's identifier is supplied as splitProfileId when creating a merchant application.
Each split profile has the following properties.
| Field | Description |
|---|---|
| id | Unique identifier for the split profile. |
| name | Name displayed in the Flute dashboard. |
| isHighRisk | Indicates whether the profile is designated for high-risk merchant applications. |
| isDefault | Indicates whether this is the user's default split profile. |
The API documentation notes that high-risk profiles are typically assigned after underwriting identifies a merchant application as high risk. The available API specification establishes the profile's purpose and assignment mechanism. It does not specify its underlying percentages, recipients, or calculation rules.