Merchant onboarding in Amaryllis is more than a digital application form. It is the operational workflow that creates the merchant record, validates the business, applies partner-specific underwriting rules, boards the merchant to the required processing infrastructure, and configures how that merchant will transact, be billed, receive statements, and operate downstream.
Four levels separate platform control from merchant operations
Configuration is inherited from the platform level down to the individual MID, allowing shared rules to be managed centrally while keeping merchant-specific settings isolated.
Operator
Defines platform-wide defaults, inherited branding, URLs, email templates, and the underwriting validation services available to partners.
Platform owner controlService Provider
Stores partner configuration: processors, payment methods, underwriting requirements, branding, statement settings, and fee framework.
Partner-level policyPlatform Account
Organizes and aggregates merchant Sub-Accounts. Each partner includes structural Platform Accounts such as Templates and Merchants.
Merchant organizationSub-Account
The MID-level operating record containing merchant identity, processing, billing, risk, statement, and transactional configuration.
Operational merchant recordSeven stages from setup to live operations
Each stage can inherit shared rules from the Service Provider while supporting merchant- or partner-specific decisions.
Platform hierarchy and inherited defaults
The onboarding process starts before a merchant applies. Operator and Service Provider settings determine which controls, processors, validation tools, and commercial rules are available downstream.
Merchant application and account creation
When underwriting is required, the Sub-Account is tied to a merchant application. Amaryllis supports both API-led and Back-Office-led application journeys.
BlytzPay
- Partial merchant applications enter through the Amaryllis Management API.
- Applications begin in Draft status.
- Missing business details and documents are completed in Back-Office.
LaCore
- Merchant applications are entered through the Back-Office portal.
- The Management API is not the application intake path in this configuration.
- Approval and boarding follow LaCore-specific controls.
At Sub-Account level, the merchant record can include Name, MID, External ID, MCC, Account Type, Contact Email, linked application, and Cut-Off Time.
Compliance and underwriting checks
The Operator defines which external validation services the platform supports. Service Providers then choose from that approved set for each underwriting template.
| Template example | Validation logic |
|---|---|
| BlytzPay · Merchant Application | LexisNexis, Mastercard MATCH, TinCheck, TransUnion US, and GIACT. |
| BlytzPay · Additional MID | Uses the core validation set without TransUnion US. |
| BlytzPay · ACH | No external underwriting validation because the workflow adds ACH to an existing credit-card merchant. |
| LaCore · Credit Card | LexisNexis, Mastercard MATCH, TinCheck, TransUnion US, and GIACT. |
Applications passing the configured scoring matrix can proceed directly to boarding. Any failed validation stops boarding and sends the application to manual review.
Successful validations still require manual approval before boarding. Failed validations also stop the workflow for review.
Payment and processing configuration
Processor and payment-method availability is controlled centrally at Service Provider level, then applied to each Sub-Account according to its merchant profile.
Processor boarding and Sub-Account creation
Boarding is workflow-driven and depends on the partner, payment method, and gateway architecture. The result is a processing-ready set of Sub-Accounts.
| Flow | Boarding | Sub-Accounts created |
|---|---|---|
| BlytzPay · Credit Card | MID boarded to TSYS and NMI because Amaryllis acts as the gateway. | Processing + Debit after both boarding steps succeed. |
| BlytzPay · ACH | No TSYS or NMI boarding required. | Processing + Debit after underwriting. |
| LaCore · Credit Card | MID boarded to TSYS only. NMI is not used because Amaryllis is not the gateway. | Sub-Accounts created after TSYS boarding succeeds. |
Integration and transaction flow
Amaryllis can operate as the gateway layer or as the control and data layer around a partner-owned gateway. The onboarding configuration determines which model each merchant enters.
Amaryllis Gateway API
- Credit card transactions flow through Amaryllis to TSYS via NMI under the configured BIN.
- NMI performs authorization; TSYS settles funds to the collecting account.
- ACH flows through Amaryllis to CFSB, with real-time GIACT account validation.
Partner-owned gateway
- LaCore integrates directly to TSYS through its own gateway.
- Amaryllis does not act as the transaction gateway.
- Transaction data is imported from TSYS TDDF files for downstream operations.
Billing and downstream setup
Onboarding finishes by attaching the merchant to the commercial and reporting structures it needs for live operations.
Clear ownership at every layer
Amaryllis keeps platform-wide policy, partner configuration, merchant organization, and MID-level operations distinct.
Built to orchestrate the onboarding ecosystem
The documented workflows connect Amaryllis with application channels, validation providers, processors, networks, and downstream operational services.
