Skip to content

Payment Topology

End-to-end (E2E) target solution architecture for adunopay — how the merchant-facing portals, the backend, the payment-method integrations, and the card-present terminal stack fit together.

Source

Ported from the Confluence page WP12 Architecture – E2E Solution Architecture (Target View). The diagram below is the exported adunopay E2E Application Architecture draw.io diagram from that page.

High-level application architecture

adunopay E2E application architecture

Diagram still shows the old branding

The exported PNG above predates the rebrand and still labels components checksum / tapypay. The Mermaid recreation below is the up-to-date one. Re-export the draw.io diagram when it is rebranded.

Tiers

Marketing / landing pages (WordPress) — the public top of the funnel:

  • checksum.ch (corporate) and tapypay.ch (product landing) — public WordPress sites where a prospective merchant first arrives and clicks through to start Onboarding. Built and likely hosted by an external agency — separate from the product. Both still carry the pre-rebrand branding and are being replaced by the in-house adunopay.ch site. See Marketing websites.

Frontends (Vercel) — Next.js apps, reached over HTTPS:

  • Partner Portal, Admin Portal, Merchant Portal, Onboarding — Administrators reach the Admin Portal; Merchants reach the Merchant Portal and Onboarding. All portals call the backend over REST API / nginx.

Backend (Informatik) — the core platform:

  • MAS ERP Backend (Node.js) — acquiring & merchant accounting; the main API the portals and terminals talk to.
  • DAO Model Access — data-access layer in front of the database.
  • boncard Worker — TWINT, Lunch-Check and boncard cron jobs for submissions.
  • IAM — identity & access management.
  • Bankenstamm Importer — bank master-data import.
  • Payout File import/export — generates pain.001 XML sent to UBS.
  • Postgres 16 — primary datastore.

Payment-method integrations — TWINT, Lunch-Check and boncard, each handling merchant onboarding and transaction authorization against the respective external network.

MPOS device (terminal) — the card-present stack:

  • Web ECR (via WebView, e.g. Glarotech) and Android ECR (Intent) feed the adunopay app through the CIA (Checksum Integration API — the acronym predates the rebrand).
  • adunopay exchanges Data & Auth with the backend over REST API / nginx.
  • tapypayConnect / Softpay (APK via SDK) handles login, config and transaction authorization. PCI data (card data, PAN, etc.) is encapsulated via Softpay & Silverflow — it does not transit the adunopay backend.

Card rails — Softpay Backend → SilverFlow (processor) → Mastercard / VISA → Issuers.

External systems — UBS (payouts), Topal ERP (bidirectional Fibu-Sync via REST/OAuth2: merchants, chargebacks, device rentals, etc.), Bank Frick (sponsor bank / affiliate license), and the payment networks above.

Diagram (editable)

A Mermaid recreation of the same topology — text-based so it can be edited in git and reviewed in PRs. The exported image above remains the source of truth; keep this in sync when the architecture changes.

flowchart LR
    admin([Administrators])
    merch([Merchants])

    subgraph marketing["Marketing (WordPress, agency-hosted)"]
        checksumch["checksum.ch<br/>(corporate)"]
        tapypaych["tapypay.ch<br/>(product landing)"]
    end

    subgraph terminal["MPOS Device (Terminal)"]
        webecr["Web ECR<br/>(WebView, e.g. Glarotech)"]
        andecr["Android ECR<br/>(Intent)"]
        cia["CIA (API)"]
        adunopay["adunopay"]
        softpayapp["tapypayConnect / Softpay<br/>(APK via SDK)"]
    end

    subgraph vercel["Vercel"]
        partner["Partner Portal (Next.js)"]
        adminportal["Admin Portal (Next.js)"]
        merchportal["Merchant Portal (Next.js)"]
        onboarding["Onboarding (Next.js)"]
    end

    subgraph backend["Backend (Informatik)"]
        mas["MAS ERP Backend (Node.js)<br/>Acquiring & Merchant Accounting"]
        dao["DAO Model Access"]
        worker["boncard Worker<br/>(TWINT, Lunch-Check, boncard cron)"]
        iam["IAM"]
        bankimp["Bankenstamm Importer"]
        payout["Payout File import/export"]
        db[("Postgres 16")]
    end

    subgraph rails["Payment-method Integrations"]
        twint["TWINT"]
        lunch["Lunch-Check"]
        boncard["boncard"]
    end

    subgraph external["External Systems"]
        ubs["UBS"]
        topal["Topal ERP"]
        frick["Bank Frick<br/>(Sponsor Bank)"]
        twintx["TWINT network"]
        lunchx["Lunch-Check network"]
        boncardx["boncard network"]
        softpaybe["Softpay Backend"]
        silverflow["SilverFlow<br/>(processor)"]
        mc["Mastercard"]
        visa["VISA"]
        issuers["Issuers"]
    end

    admin -->|https| adminportal
    merch -->|https| merchportal
    merch -->|https| checksumch
    merch -->|https| tapypaych
    checksumch -->|start onboarding| onboarding
    tapypaych -->|start onboarding| onboarding

    partner -->|REST API / nginx| mas
    adminportal -->|REST API / nginx| mas
    merchportal -->|REST API / nginx| mas
    onboarding -->|REST API / nginx| mas

    mas --> dao
    worker --> dao
    iam --> dao
    bankimp --> dao
    dao --> db
    payout -->|pain.001 XML| ubs
    bankimp <-->|REST OAuth2 / Fibu-Sync| topal
    bankimp --> frick

    mas --> twint --> twintx
    mas --> lunch --> lunchx
    mas --> boncard --> boncardx

    webecr --> adunopay
    andecr --> adunopay
    cia --> adunopay
    adunopay -->|Data & Auth, REST / nginx| mas
    adunopay --> softpayapp
    softpayapp -->|Transaction Authorization| softpaybe
    softpaybe --> silverflow
    silverflow --> mc --> issuers
    silverflow --> visa --> issuers

Hosting & infrastructure

Where the adunopay software actually runs. The application architecture above is logical; this section maps each tier to its physical/cloud host.

Some details are unconfirmed

Entries marked (to confirm) are best-guess and need verifying by someone with infra access. Correct them in place and drop the marker once checked.

Where each tier runs

Component Host Notes
Marketing sites — checksum.ch, tapypay.ch (WordPress) Agency-managed — host unknown (to confirm) Public funnel into Onboarding; see Marketing websites.
Frontends — Partner, Admin, Merchant & Onboarding portals (Next.js) Vercel The four portals from the diagram.
Backend / API — MAS ERP Backend (Node.js) + nginx, the green API box Dedicated Linux server at hostpoint.ch Hosts the core platform the portals and terminals call over REST API / nginx. (to confirm)
Database — Postgres 16 Unknown — same server as the backend? (to confirm) See Database below.
Test / sandbox environment Unknown (to confirm) See Test environment below.

Test environment

Where the Dev / Sandbox environment(s) are hosted, and how they relate to production (separate server, separate Vercel project, separate database?).

To confirm

  • Where is the test/sandbox environment hosted?
  • Is it isolated from production data?

(The source Confluence page has an "Available Environments" diagram — E2E_Environments_DevSandboxProd.drawio — not yet ported; see below.)

Database

The primary datastore is Postgres 16 (labelled checksum in the exported diagram — a pre-rebrand name).

To confirm

  • Does the database run on the same hostpoint.ch server as the backend, or on separate/managed infrastructure?
  • How is it provisioned and accessed?

Encryption at rest

Whether stored data — the Postgres database, backups, and any file storage — is encrypted at rest, and how the keys are managed. Relevant to PCI-DSS, which requires protection of stored cardholder data (note that card data does not transit the adunopay backend — it is encapsulated via Softpay & Silverflow — but merchant and account data is still in scope).

To confirm

  • Is the Postgres 16 database encrypted at rest (e.g. disk/volume encryption, or transparent data encryption)?
  • Are backups encrypted, and where are the keys stored?
  • Is data in transit encrypted end-to-end (TLS on the backend / nginx, DB connections)?

Monitoring & logging

How service health is monitored is not yet documented; each tier writes its own logs (backend on the hostpoint server, frontends in Vercel). Detail to be filled in — what's monitored, where alerts go, and exact log locations — lives in the Operations & observability how-to.

DNS & domain registrar

The adunopay domains — including adunopay.ch, the legacy checksum.ch and tapypay.ch (still live — see Glossary → adunopay), and several others — are registered and managed at Infomaniak (infomaniak.ch), a Swiss hosting and domain provider. Infomaniak is both the registrar (it holds the domains) and where DNS records are configured, unless a specific domain has nameservers delegated elsewhere.

Credentials live in 1Password, not here

The Infomaniak login belongs in 1Password, not on this page — this section records only who the registrar is.

To confirm

  • The full list of domains held under the Infomaniak account.
  • Whether any domain delegates DNS to another provider (e.g. Cloudflare in front of the marketing sites) rather than resolving at Infomaniak.

Backups

How and where adunopay systems are backed up.

To confirm

  • What is backed up (database, server config, application state)?
  • Where are backups stored, how often, and how is restore tested?

Not yet ported

The source Confluence page also contains material that could not be brought over automatically (binary / non-text assets):

  • Available Environments diagram (E2E_Environments_DevSandboxProd.drawio) — Dev / Sandbox / Prod environment layout.
  • checksum_architektur.docx (German) — detailed target-system write-up.

Export these from Confluence (draw.io → Export as PNG/SVG; doc → Markdown) and drop them in docs/assets/ to add them here.