Appendix

Basic understanding of the card business

This chapter contains a brief description of the most important roles for scheme-based payment cards. More detailed information can be found, for example, in the following source: https://www.swiss-payment-association.ch/kreditkarten/kreditkartensystem

Role model for issuing cards

Depending on the provider, some roles might be covered by the same organization.

Cardholder:

• Uses the payment card as payment instrument.
• Has a contractual relationship with the issuer.

Distribution Partner:

• Is selling cards legally offered by issuers to cardholders by using his own brand.
• Does not directly own the data about payment cards and transactions. But access to these data can be possible based on the contractual setup between issuer and cardholder without an explicit con-sent of the cardholder.
• Can take over some duties and obligations for the card issuing, depending on the contract with the card issuer.

Card Issuer:

• Bank or other organization which is legally issuing a payment card under a certain payment scheme (e.g. Mastercard, Visa, American Express, others) to cardholders.
• Is responsible that payment cards and the issuer-side processing follow the rules of the payment scheme.
• Manages the payment cards of cardholders, authorizes transactions, and guarantees towards the scheme and acquirer the payment of valid authorizations.
• Is directly the owner of data about payment cards and transactions.
• Card issuers in Switzerland are for example banks, Cembra, Swisscard, Viseca Card Services.

Card Service Provider:

• Is operating the card and transaction processing on behalf of the card issuer.
• Has a contract with the card issuer.
• Can cover many parts of scheme and legal regulations as service for the card issuer.
• Card Service Providers in Switzerland are for example UBS Card Center, SIX, Viseca Payment Ser-vices.

Processor:

• Provides services for the card service provider related to the card management and transaction pro-cessing.
• Has a contract with the Card Service Provider.

Embosser:

• Is producing the physical card upon request of the card issuer.
• Has a contract with the card issuer.

Role model for processing transactions (OUT OF REVIEW SCOPE)

Several players are needed to enable cashless payments:

Payment Scheme

A company that offers card products and services and defines the associated card brands associated card brands, processing rules and fee structures (interchange and payment scheme fees). It also controls the standards and handles the central processing of card transactions such as authorization, clearing and settlement.

Acquirer

The bank or institution with a contractual business relationship with the merchant, which settles the card transaction data submitted by the merchant with the respective card issuer via the corresponding payment scheme.

Merchant

Physical points of sale (POS), virtual web stores (e-commerce) or ATMs that accept card payments.

Issuer

The card issuer manages the card accounts of its customers, authorizes card transactions and guarantees the acquirer the settlement of valid card transactions.

Cardholder

Uses the prepaid, debit or credit card as a means of payment.

Use cases for transaction processing and mapping in Card API (OUT OF REVIEW SCOPE)

Authorization and transaction standard

Authorization: involves the process of authorizing financial transactions by verifying the user's identity and confirming authorization for the transaction. This includes the verification of account information, security features and other relevant data to ensure that the transaction is legitimate and can be executed within the usable spending limit.

Transaction: Transaction (booking) describes the actual execution of the financial transaction. This includes payments to third parties (e.g. merchants), the transfer of funds between accounts or other financial activities. The transaction is processed according to the user's authorized instructions and all relevant information is logged and secured.

Matching: The API user does not have to worry about matching for this use case. Authorization and transaction are mapped via the status of the Transactions entity. There are separate identifiers for authorization and transaction.

Reservation and transaction

Matching between authorization, update and transaction

Reservation: A reservation is a temporary blocking of funds in an account for a specific transaction. In the case of a reservation, the amount is temporarily deducted from the available balance to ensure that sufficient funds are available for the transaction before it is actually carried out.

Authorization: Authorization is carried out to confirm the authorization for the reservation and to ensure that the transaction is legitimate.

Update: Updates may occur during the reservation period, e.g. if the status of the transaction changes or additional information is required.

Transaction: The actual transaction takes place when the reservation is released and the money is actually transferred

Matching: Matching of an authorization to the corresponding entry for the update and finally to the transaction (booking).

Beispiel: Einkauf von Flugtickets bei einer Fluggesellschaft Ein Kunde bucht online Flugtickets bei einer Fluggesellschaft und gibt seine Kreditkartendaten ein. Die Autorisierung erfolgt, um sicherzustellen, dass der Kunde über ausreichende Mittel auf seinem Konto verfügt und die Transaktion legitim ist.

In einigen Fällen kann eine Buchung für Flugtickets in Teilzahlungen aufgeteilt werden, aber letzt-endlich nur eine einzelne Buchung erfolgen. Jede Teilzahlung wird als separate autorisierte Transak-tion angezeigt, bevor sie zu einer einzigen endgültigen Buchung zusammengefasst wird. Kunden können auch ihre Buchungen stornieren oder ändern, was dazu führen kann, dass autorisierte Transaktionen erstattet und neu autorisiert werden müssen. Dies kann zu mehreren autorisierten Transaktionen führen, bevor die endgültige Buchung abgeschlossen ist.

Transaktion (Buchung): Sobald alle vorherigen Schritte abgeschlossen sind, wird die eigentliche Bu-chung durchgeführt. Der Geldbetrag wird vom Konto des Kunden abgebucht und auf das Konto des Händlers überwiesen.

In solchen Fällen ist es wichtig, sicherzustellen, dass die autorisierten Transaktionen mit der endgül-tigen Buchung übereinstimmen und zur Buchung zugeordnet werden können.

This use case is mapped differently in the transaction data depending on the card service provider.

Reversal / Chargeback

A reversal refers to the reversal of an already authorized transaction. This can occur for various reasons, e.g. due to an error in the transaction (if a transaction was accidentally double-booked), fraudulent activity or a customer request. The reversal reverses the original transaction and the funds are credited back to the sender's account.

Use case: Matching between two authorizations. In such cases, it is important to be able to correctly assign the original and former authorized transaction to the authorized transaction for the reversal.

Credit note

Matching between two transactions

A credit note is a transaction in which funds are transferred to the recipient's account. Matching between two transactions can occur in this context if, for example, a repayment or refund is made for a previously authorized transaction.

Use case: Matching between two transactions for a credit transaction.

Example: Authorized transaction: A customer makes a purchase in an online store and pays with their card. The transaction is authorized and the amount is debited from the customer's account.

Cancellation or refund: The customer later decides to return the purchased item or an error occurs during delivery. The retailer then carries out a cancellation or refund to return the amount to the customer.

When matching these two transactions, the original authorized transaction is linked to the credit note for the refund. This makes it clear that the refund is related to the original transaction and that the amount was refunded correctly.

In this way, the two transactions can be tracked.