Digital Onboarding (Full Solution)¶
End-to-end digital onboarding for a full acquirer setup — taking a merchant from initial data capture through risk assessment, contract and payout setup, system readiness, and final go-live communication.
Source
Ported from the Confluence page Digital Onboarding (Full Solution) (space CS). Confluence remains the working source for this still-evolving process; this page is the published snapshot — keep it in sync when the Confluence page changes.
At a glance¶
| Purpose | Outline digital onboarding for full acquirer setup. |
| Inputs | Information from or related to the merchant (data, identification, verification, etc.). |
| Outputs | Full merchant setup ready for transactions (Acceptance & Acquiring). |
| Process owner | TBD |
Current scope restrictions¶
Digital onboarding currently applies only to the simplest cases:
- Simple merchant structure only — a main merchant plus flat underlying stores with one single bank account.
- End-to-end solutions only — adunopay + hardware (optional) + acquiring. Explicitly no "acquiring only" solution is onboarded digitally.
Anything outside these bounds is handled manually — see Out-of-scope topics.
High-level functional blocks¶
The flow is organized into these blocks, each described below:
flowchart LR
A[Digital Onboarding] --> B[Risk Assessment<br/>& Statement]
B --> C[Contract & Payout]
C --> D[System Readiness]
D --> E[Merchant Communication]Digital onboarding¶
Some thoughts on process design:
- Merchant info first — start with merchant type, as it (at least partly) defines the data that follows.
- Merchant data before product selection — to be discussed; in principle it is just a question of ordering.
- Shopping cart at the end (potential) — so merchants can already pay digitally/online for their order.
Process description¶
Focus
Only process steps that might differ from the legacy adunopay onboarding are described here.
Step: Get merchant info¶
Start with merchant type, since it partly determines the person data required in the next step. This is also the start of KYB: collect enough business-entity information to verify that the merchant legally exists, operates under the declared legal form, and is requesting onboarding for a business activity adunopay can support.
Step: Get person data¶
The merchant type from Get merchant info drives what person data is collected:
| Merchant type | Person data required |
|---|---|
| Sole proprietorship | The "onboarder" represents all 3 roles: Contact, Signatory, and Ultimate Business Owner (UBO). |
| General Partnership (Kollektivgesellschaft), Corporation (AG), Limited Liability Company (GmbH), Cooperative (Genossenschaft) | All 3 roles must be defined explicitly. Every owner with a company share ≥ 25% must be added as a UBO. |
| Association (Verein), Foundation (Stiftung), Limited Partnership (Kommanditgesellschaft) | Only Contact info is completed in the flow (other roles are not relevant). The rest of the data collection happens manually between adunopay and the merchant after the flow above completes. |
Identification & verification
- In principle, only an ID or passport is used for identification.
- The country of the passport is irrelevant — it only needs to uniquely identify the person.
- Exceptions (e.g. an expired passport from a critical country such as Syria, where the Swiss Aufenthaltsgenehmigung might be used instead) must be flagged and documented as an exception, with the reasons for approval recorded.
- [ ] Add link to the AML policy and Risk strategy documents (from Tiago).
Step: Select product¶
Step 1 — Select adunopay product. Chosen first, as it includes prices for the adunopay license, hardware, and acquiring:
- adunopay GO
- adunopay MAX
Step 2 — Select adunopay product. Keep it simple → one product; move hardware selection to the Merchant Portal:
- N × Phone License
- N × SUNMI V3H
- N × SUNMI L3
- N × Urovo Neo
This information could be collected in a shopping cart, payable at the end of onboarding (optional).
Step: Select payment schemes¶
When showing the payment schemes, use commissions based on the adunopay product (adunopay GO vs. adunopay MAX).
Long term
Add additional payment schemes later — e.g. Boncard, AMEX, Diners/Discover, UPI, Crypto.
Step: Enter discount codes¶
Discount codes should be linked directly to the data in the Pricing Engine. Keep three pricing domains explicitly separate:
| Pricing domain | Basis |
|---|---|
| adunopay license | adunopay GO vs. adunopay MAX (or a dedicated setup). |
| Hardware | Hardware cost (or potentially rental cost?). |
| Acquiring | Commissions. |
Additional pricing topics may be added later — e.g. service fees and non-payment accessories (charging cradle, receipt paper, etc.).
Digital onboarding out-of-scope topics¶
The following are explicitly not covered by digital onboarding and are handled as a manual process:
- The actual merchant structure itself.
- Complex merchant structures, including non-flat store structures.
- More than one bank account assigned to the merchant structure.
For the MVP, more complex setups are done manually by adunopay; later, some of this may move to merchant self-service.
Bank account changes
A bank account probably cannot be changed by the merchant (AML). A self-service change is a request towards the Acquirer, not a direct edit.
Risk assessment and statement¶
Process description¶
Additional points (added after discussion with Simone):
- KYB / business verification — verify the business entity before onboarding: legal name, legal form, registration data, business address, ownership/control structure, UBO data, and whether the declared activity matches public/company-register evidence. KYB evidence feeds the KYC, AML, and sanction screening statement.
- NOGA / MCC mapping — when extracting the Zefix extract, use the NOGA code and map it against the MCC / business domain selected by the merchant. If it does not map → manual review.
- MCC selection — offer all possible MCCs so the merchant picks the ones that best fit their business. This raises the chance of catching MCCs we don't want (otherwise the merchant just picks anything that loosely fits).
- IBAN correctness — make sure by all means that the IBAN is correct and linked to the business; the best way is to do the bank transfer.
- IBAN change requests — apply the same checks for requested IBAN changes. If possible, implement a regular check of IBAN information against merchant information in MAS.
- Additional data to request:
- ATV (Average Ticket / Transaction Value).
- Yearly revenue expectation (for the business the merchant is requesting).
- Scheme checks — perform MATCH (Mastercard) and VMSS (Visa) checks with the schemes.
- Multiple terminals — when more than one terminal is requested, check whether it makes sense for the given merchant (to avoid unrelated business such as renting out devices).
- eCommerce warning — eCom is a different business and needs additional and different checks.
A written statement and conclusion of the process steps must be produced. For the MVP, one statement may be sufficient; ideally a statement is produced for each of the three checks:
A GUI in the Admin Portal must support this and must not be visible to the merchant.
Mandatory sanction screenings¶
The following screenings are mandatory to execute:
- US Office of Foreign Assets Control (OFAC) — e.g. Specially Designated Nationals (SDN).
- US Department of State.
- Consolidated Sanctions — e.g. Sectoral Sanctions Identification (SSI), Non-SDN Iranian Sanctions Lists, CAPTA.
- European Union.
- United Nations — e.g. the Compendium of UN Security Council Sanctions.
- Switzerland's State Secretariat for Economic Affairs (SECO).
- Politically Exposed Persons (PEP).
Prohibited merchant categories¶
Must not be onboarded in Nurture
Per Visa communication (18 May 2026), merchants in the following categories must not be onboarded:
| Category | MCC |
|---|---|
| Adult Content | 5967 |
| Dating and Escort Services | 7273 |
| Gambling | 7995 |
| Pharmacies | 5122, 5912 |
| Crypto Merchants | 6051, 6012 |
| Cyberlockers | 4816 |
| Games of Skill | 5816 |
| High Integrity Risk Financial Trading Platforms | 6211 |
| Outbound Telemarketing | 5966 |
| Subscription "Negative Option" Merchants | 5968 |
| Tobacco Sales | 5993 |
Contract and payout¶
Process description¶
TBD — to be completed from the source page as it develops.
System readiness¶
Process description¶
TBD — to be completed from the source page as it develops.
Merchant communication¶
Process description¶
At the very end, send an email to the merchant confirming that:
- The acceptance product is ready to be used (for adunopay on OTC products).
- The adunopay product is being shipped (for adunopay on adunopay SUNMI / Urovo products).
Not yet ported¶
The source Confluence page contains placeholder sections and diagrams that are not yet reflected here:
- Diagrams referenced by the risk-assessment section (the MATCH / VMSS
scheme-check flow). Export from Confluence (draw.io → Export as PNG/SVG) and
drop into
docs/assets/. - Contract and payout and System readiness process descriptions, still empty/TBD on the source page.