跳至正文
cube4devcube4dev
Minimal Organization: PALVIQ, Zahlungsdienstleister – das Gelände im Modell von schräg oben

模拟 · Minimal Organization · Money and insurance

Payment service provider

A payment service provider as a walkable model: a card payment from authorisation in milliseconds to the payout to the merchant in the morning.

All data are fictional – PALVIQ does not exist. The model can be filled with your company's real data and then shows what is hard to see today: transactions per second, sale days included, or the runtime of the clearing run night after night.

The card payment process – authorisation, clearing and payout – as a running model. At PALVIQ, a fictional payment service provider, every payment has two speeds. Authorisation between checkout, card scheme and the cardholder's bank takes milliseconds. The money only reaches the merchant through the clearing run at 10 pm and the payout at 6 am. The target in the model: money with the merchant within three days of the purchase.

The site has headquarters, an operations centre and data centres A and B. Stricter fraud rules ask for confirmation in the banking app more often – safer, but more purchases are abandoned. If data centre A fails, everything runs via B and responses slow down. In card testing, fraudsters try out stolen cards with thousands of tiny payments. Alongside, a merchant becomes a customer and a cardholder raises a chargeback.

The shares of confirmations, abandonments and declines are model assumptions. Documented in the sources: the licensing requirement, strong customer authentication, safeguarding of customer funds and the four-party model. This page is for management, risk, IT, merchant sales and onboarding.

A card payment becomes money for the merchant

  1. 01

    Checkout at the merchant: Someone shops online and enters a card.

  2. 02

    Gateway and tokenisation: The gateway replaces the card number with a token.

  3. 03

    Fraud scoring: A model scores the payment in milliseconds.

  4. 04

    Declined.

  5. 05

    Confirmation in the banking app: The cardholder confirms in their bank's app.

  6. 06

    Purchase abandoned.

  7. 07

    Authorisation via the card scheme: The request runs through the card scheme to the cardholder's bank.

  8. 08

    Decision by the cardholder's bank: The cardholder's bank checks funds and risk.

  9. 09

    Not approved.

  10. 10

    Response to the merchant: The merchant gets the approval – the purchase is done.

  11. 11

    Shipping and capture: When shipping, the merchant captures the amount.

  12. 12

    Clearing run to the schemes (10 pm): At night the settlement goes to the card schemes.

  13. 13

    Payout to merchants (6 am): In the morning the money minus fees goes to the merchant.

  14. 14

    With the merchant.

How a payment service provider can use the model

  • Internal communication

    Merchant sales, onboarding, fraud detection, settlement and control functions on one site: everyone sees how their work hangs on the same payment.

    适用对象Management, internal comms

  • Onboarding

    The chain of a card payment in the processes view explains the four-party model to new colleagues: what merchant, card scheme and the cardholder's bank each do.

    适用对象New staff in every department

  • Training

    The disruption ‘Card testing’ shows an attack with thousands of tiny payments and how it is fended off: for six hours, one and a half times as many payments arrive.

    适用对象Fraud prevention, new analysts

  • Explaining to customers

    Merchants see when their money arrives: authorisation in milliseconds, clearing at 10 pm, payout at 6 am. ‘Year, week, day’ puts it all side by side.

    适用对象Merchant sales, merchant support, merchants

  • Strategic overview

    The ‘Fraud rules’ control makes the trade-off between security and revenue visible, and ‘What the work depends on’ shows the impact of an outage per system.

    适用对象Management, risk management, head of IT

What is shown – why – for whom

展示内容 为什么 适用对象
Diagram ‘Year, week, day’: authorisation, clearing at 10 pm, payout at 6 am 为什么Explains when merchants have their money. 适用对象Merchants, sales
Diagram ‘What the work depends on’: gateway, fraud scoring, ledger, two data centres 为什么Shows the impact of an outage per system. 适用对象Head of IT, supervisors, business continuity
Diagram ‘What each control does’: fraud rules versus abandoned purchases 为什么Makes the trade-off between security and revenue visible. 适用对象Risk management, merchant support
Diagram ‘Where the time goes’ until the money reaches the merchant 为什么Shows where the three days come from. 适用对象Finance, merchants
Chain of a card payment in the four-party model (Processes view) 为什么Explains what merchant, card scheme and bank each do. 适用对象Onboarding, customers
Disruption ‘Card testing’ 为什么Shows the attack with tiny payments and how it is fended off. 适用对象Fraud prevention, training
Process ‘A merchant becomes a customer’ with the control ‘Risk analysts’ 为什么Shows how new merchants are classified. 适用对象Sales, risk

Departments in the model

  • Management

    Runs the payment institution, responsible for risk and compliance.

  • Merchant sales

    Wins online shops and stores as customers.

  • Onboarding

    Checks new merchants: register, owners, sanctions lists.

  • Risk

    Assigns merchants to risk classes, sets limits and reserves.

  • Fraud detection

    Rules and learning models that score every payment in milliseconds.

  • Chargebacks

    Handles cardholder disputes.

  • Settlement

    Pays merchants and keeps customer funds separate from own money.

  • Platform operations

    Gateway, data centres, control room – around the clock.

  • Security

    Protects card data; few may enter the protected zone.

  • Compliance and AML

    Enhanced checks of risky merchants, suspicious activity reports.

  • Finance

    Fees, costs, liquidity.

All processes in the model

A card payment becomes money for the merchant

  1. 01Checkout at the merchant: Someone shops online and enters a card.
  2. 02Gateway and tokenisation: The gateway replaces the card number with a token.
  3. 03Fraud scoring: A model scores the payment in milliseconds.
  4. 04Declined.
  5. 05Confirmation in the banking app: The cardholder confirms in their bank's app.
  6. 06Purchase abandoned.
  7. 07Authorisation via the card scheme: The request runs through the card scheme to the cardholder's bank.
  8. 08Decision by the cardholder's bank: The cardholder's bank checks funds and risk.
  9. 09Not approved.
  10. 10Response to the merchant: The merchant gets the approval – the purchase is done.
  11. 11Shipping and capture: When shipping, the merchant captures the amount.
  12. 12Clearing run to the schemes (10 pm): At night the settlement goes to the card schemes.
  13. 13Payout to merchants (6 am): In the morning the money minus fees goes to the merchant.
  14. 14With the merchant.

A merchant becomes a customer

  1. 01Online application: An online shop applies to accept cards.
  2. 02Register and owners automatically, website and sector by hand – at the same time.
  3. 03Automatic merchant check: Commercial register, beneficial owners, sanctions lists.
  4. 04Check of website and sector: What does the shop really sell?
  5. 05Checks done.
  6. 06Assign risk class: The risk team sets the risk class.
  7. 07Enhanced due diligence: Compliance checks in depth: source of funds, business model.
  8. 08Declined.
  9. 09Set limits and reserve: Limits and a reserve for possible chargebacks are set.
  10. 10Registration with the card scheme: The merchant is registered with the card scheme by sector.
  11. 11Integration in test mode: The merchant's developers integrate and test.
  12. 12Live.

A cardholder disputes

  1. 01Cardholder disputes with their bank: A cardholder tells their bank: goods never arrived.
  2. 02Review chargeback: The chargeback team assigns the case and debits the merchant.
  3. 03Merchant provides evidence: The merchant provides proof of delivery – or accepts.
  4. 04Refunded.
  5. 05Representment with evidence: The team contests with the evidence.
  6. 06Card scheme decides: The card scheme decides, if necessary in arbitration.
  7. 07Decided.

What you can change

Controls

  • Transaction volume: On sale days almost twice as much comes in.
  • Fraud rules: Stricter rules require confirmation more often – more purchases are abandoned.
  • Clearing run: How much the nightly run can settle.
  • Risk analysts: How many new merchants are classified at once.

Disruptions

  • Data centre A down: For three hours everything runs via data centre B: responses get slower. Severe IT incidents must be reported.
  • Ledger failure: Eight hours without the ledger: if a clearing or payout run falls into it, merchants wait a day longer.
  • Card testing: Fraudsters test stolen cards with thousands of tiny payments: for six hours one and a half times as many payments.

What the model gives a payment service provider

  • 01

    Milliseconds and one night

    Authorisation, the nightly clearing run and the morning payout run in one model. You see why days pass between purchase and money.

  • 02

    A trade-off you can measure

    Stricter fraud rules mean more confirmations and more abandoned purchases. ‘What each control does’ shows both together.

  • 03

    Play through outages

    Data centre A, ledger, card testing: trigger each disruption. If the ledger failure falls on a clearing run, merchants wait a day longer.

  • 04

    Black Friday in advance

    Set ‘Transaction volume’ to the sale day: almost twice as much. The simulation shows whether the nightly run keeps up before the day arrives.

  • 05

    Made to be shown

    A walkable 3D model in the browser and on large projections – calm to look at, rather than one more wall of numbers.

Basis and limits

Fictional payment provider · model based on researched industry structures and regulation · no forecast for real companies

1 case = 1000 card payments, 1 merchant or 1 dispute · 1 figure ≈ 10 employees

All volumes, durations, rates and capacities are model assumptions, not values of a real payment provider.

Shares of challenges, abandonments and declines as well as chargeback deadlines are model assumptions; card scheme rules differ.

Documented: licensing, strong customer authentication with exemptions, safeguarding of customer funds, card data protection, four-party model.

Public sources the model is based on:

  • Richtlinie (EU) 2015/2366 (PSD2)
  • BaFin: Zahlungsinstitute und E-Geld-Institute
  • Geldwäschegesetz
  • PCI Security Standards Council
  • Verordnung (EU) 2015/751 (Interchange)
  • Delegierte Verordnung (EU) 2018/389 (starke Kundenauthentifizierung)

Your payments business as a model

Would you like to see your payment chain, merchant onboarding or clearing runs like this? Get in touch by email or phone and we'll work out which data belong in the model. We'll send the password to start PALVIQ on request.

如有兴趣,请索取密码 →

就此咨询

Minimal Organization: Zahlungsdienstleister

您填写的信息仅发送至本网站,且仅用于答复您。

Similar business models

← Minimal Organization

All data are fictional – PALVIQ does not exist. The model can be filled with your company's real data and then shows what is hard to see today: transactions per second, sale days included, or the runtime of the clearing run night after night.