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.

PLATFORM HIERARCHY

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.

LEVEL 1

Operator

Defines platform-wide defaults, inherited branding, URLs, email templates, and the underwriting validation services available to partners.

Platform owner control
LEVEL 2

Service Provider

Stores partner configuration: processors, payment methods, underwriting requirements, branding, statement settings, and fee framework.

Partner-level policy
LEVEL 3

Platform Account

Organizes and aggregates merchant Sub-Accounts. Each partner includes structural Platform Accounts such as Templates and Merchants.

Merchant organization
LEVEL 4

Sub-Account

The MID-level operating record containing merchant identity, processing, billing, risk, statement, and transactional configuration.

Operational merchant record
END-TO-END WORKFLOW

Seven stages from setup to live operations

Each stage can inherit shared rules from the Service Provider while supporting merchant- or partner-specific decisions.

1
CONFIGURE THE ENVIRONMENT

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.

Operator defaultsBranding, onboarding emails, Back-Office URL, developer portal URL, supported validation services.
Service Provider controlsCredit card, ACH, payout and card-on-file processors; card brands; underwriting requirement; statement settings.
Underwriting experienceIframe branding, resubmission URL, draft URL, and partner-specific application behavior.
Platform Account structureCreates the organizational layer under which merchant Sub-Accounts are grouped and managed.
2
CAPTURE THE MERCHANT

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.

EXAMPLE CONFIGURATION

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.
EXAMPLE CONFIGURATION

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.

3
VALIDATE & DECIDE

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.

TinCheckMastercard MATCHLexisNexisTransUnion USTransUnion CanadaPlaidGIACT
Template exampleValidation logic
BlytzPay · Merchant ApplicationLexisNexis, Mastercard MATCH, TinCheck, TransUnion US, and GIACT.
BlytzPay · Additional MIDUses the core validation set without TransUnion US.
BlytzPay · ACHNo external underwriting validation because the workflow adds ACH to an existing credit-card merchant.
LaCore · Credit CardLexisNexis, Mastercard MATCH, TinCheck, TransUnion US, and GIACT.
BlytzPay · Auto-approval

Applications passing the configured scoring matrix can proceed directly to boarding. Any failed validation stops boarding and sends the application to manual review.

LaCore · Semi-approval

Successful validations still require manual approval before boarding. Failed validations also stop the workflow for review.

4
DEFINE HOW THE MERCHANT TRANSACTS

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.

Transaction modeProcessing, Import, or Echo.
Payment methodsCredit Cards, ACH, BNPL, and Recurring Billing.
Card processingSupported card brands, processor, auto-capture, 3-D Secure, and tokenization method.
Risk controlsFraud-service policies and transaction-limit policies by transaction/payment/card type.
ACH validationGIACT can validate bank account status and ownership and return a score used for approval or decline.
Merchant statementsActivation, delivery details, and email distribution can be configured at Sub-Account level.
5
BOARD THE REQUIRED RAILS

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.

FlowBoardingSub-Accounts created
BlytzPay · Credit CardMID boarded to TSYS and NMI because Amaryllis acts as the gateway.Processing + Debit after both boarding steps succeed.
BlytzPay · ACHNo TSYS or NMI boarding required.Processing + Debit after underwriting.
LaCore · Credit CardMID boarded to TSYS only. NMI is not used because Amaryllis is not the gateway.Sub-Accounts created after TSYS boarding succeeds.
6
CONNECT TRANSACTION OPERATIONS

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.

BLYTZPAY FLOW

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.
LACORE FLOW

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.
7
MAKE THE MERCHANT OPERATIONAL

Billing and downstream setup

Onboarding finishes by attaching the merchant to the commercial and reporting structures it needs for live operations.

Inherited commercial frameworkFees, taxes, reserves, interchange regions, and fee groups originate at Service Provider level.
Merchant billing rulesSub-Accounts select available fee structures and can apply source/target overrides.
Advanced pricingBuyrates, reversals, seasonal fees, per-transaction fees, and split fees.
Statements & notificationsMerchant statements can be activated and automatically delivered by email.
RESPONSIBILITY MODEL

Clear ownership at every layer

Amaryllis keeps platform-wide policy, partner configuration, merchant organization, and MID-level operations distinct.

OperatorDefines inherited defaults and the validation services available across the platform.
Service ProviderOwns partner-specific onboarding, processor availability, underwriting, branding, and fee framework.
Platform AccountOrganizes and aggregates merchant Sub-Accounts.
Sub-AccountStores MID-level identity, processing, billing, risk, statement, and transaction configuration.
APIs & Back-OfficeSupport automated application intake plus operational completion and manual review.
External ecosystemConnects validation services, processors, gateways, banks, and transaction data sources.
SYSTEMS & INTEGRATIONS

Built to orchestrate the onboarding ecosystem

The documented workflows connect Amaryllis with application channels, validation providers, processors, networks, and downstream operational services.

Amaryllis Management APIBack-Office PortalAmaryllis Gateway APILexisNexisMastercard MATCHTinCheckTransUnionGIACTPlaidTSYSNMICFSB