Transaction Types

Overview

The SOAP interface specification does not replace the specific requirements outlined in card scheme rules within payment systems. Instead, it provides a comprehensive framework that outlines guidelines and procedures for card authorisation and financial capture across various scenarios.

Payment processing can be carried out through two distinct methods: the Single Message System (SMS transactions) and the Dual Message System (DMS transactions).

Transaction Type Usage

It is important to note that this specification works in conjunction with, rather than replaces, the card scheme rules governing card authorisation and transaction submission, especially for e-commerce transactions. These rules must be followed alongside this specification. For example, considerations such as the permissible difference between authorised and transaction amounts, as well as timeframes for transaction capture, are to be aligned with card scheme rules.

Supported Card Brands

• Mastercard International Incorporated - Mastercard;
• Visa International Service Association - Visa;
• UnionPay International Co., Ltd. - UPI.

Unless otherwise specified, this documentation applies to all three above mentioned card brands. Brand specific details are described in their dedicated sections of this documentation and/or specified in the footnotes.

SMS Transactions

SMS transactions encompass both card authorisation and financial capture within a single event. These transactions are suitable when immediate goods or service delivery is intended.

SMS transactions in Visa are termed as “Authorisation for a Final Transaction Amount”, whereas in Mastercard, they are referred to as “Final Authorisation”.

DMS Transactions

In contrast to SMS transactions, DMS transactions involve separate events for card authorisation and financial capture. DMS transactions should be used when the delivery of goods occurs some time after the purchase.

It is noteworthy that the financial capture can be conducted for an amount different (lower) from the authorised sum; however, adherence to card scheme rules is essential. SOAP interface itself does not validate the consistency between authorised and processed amounts during the financial capture process.

DMS Transactions encompass specific authorisation types and processing rules: "Estimated Authorisation" as defined by Visa and "Pre-authorisation" as designated by Mastercard, highlighting the distinct authorisation methods and processing protocols established by these payment systems for DMS transactions.

Payment Scenario Types

In our payment system, all payment executions follow a structured two-step process, with the exception of DMS payments:

Step 1 - This step is designed to enhance communication fault resistance. During this step, a request with minimal details is sent to the EBPP component for the sole purpose of retrieving the paymentID;
Step 2 - This is where the actual payment execution takes place. Instead of using biller and instrument reference values or a switchingID, the paymentID is used. In this step, the request should include all remaining mandatory and optional details, along with confirmed and finished elements.

Payment Cancel / Return Execution

The cancellation of payments varies throughout the different phases of the payment lifecycle. Below, you'll find the cancellation scheme for three-step scenarios. In two-step-based scenarios, Step 3 is executed concurrently with Step 2, making the use of CancelRequest inappropriate. Subsequent chapters delve into this matter with more comprehensive details.

Payment Cancel Execution

If there arises a need to cancel a payment during the payment execution process, it can be accomplished by utilizing the web service's CancelRequest method with the corresponding paymentID. It is important to note that payment cancellation is viable even when the payment has not yet reached the finished state. In most cases, this can be done after Step 1, and in the case of simple payments within the DMS scenario, it can be executed after Step 1 or Step 2.

The invocation of the CancelRequest method serves to tidy up the payment within the RTPS EBPP component. For payments that were originally created within the simple payment scenarios, such as SMS, QCash or DMS, and if deemed necessary in accordance with the system's internal logic, a reversal request may also be generated to unblock funds on the cardholder's account.

    <!-- CancelRequest -->

    <soap-env:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/">
    <soap-env:Body>
        <urn:CancelRequest xmlns:urn="urn:PaymentServer">
        <paymentID>${paymentID}</paymentID>
        </urn:CancelRequest>
    </soap-env:Body>
    </soap-env:Envelope>

Payment Return Execution

Payment return execution involves the complete return of the original transaction amount back to the cardholder's account. Please note that it is not possible to return a partial amount of the original transaction. The return execution relies on the details from the original authorisation.

However, it is essential to be aware that payment return execution is not permissible for certain transaction types, including P2P, B2P, OG, A2A, FT, PD, and SDWO.

Starting from January 15th 2022, the option to execute a return for a refund operation is also available.

    <!-- Return payment -->

    <soap-env:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/">
    <soap-env:Body>
        <urn:ReturnPayment xmlns:urn="urn:PaymentServer">
        <paymentID>${paymentID}</paymentID>
        </urn:ReturnPayment>
    </soap-env:Body>
    </soap-env:Envelope>

Payment Result Retrieval

In cases where SOAP response messages are lost due to communication failures, you have the option to retrieve them from RTPS EBPP by utilizing the GetPayment method. It is important to note that information about payments can be retrieved multiple times as needed.

This retrieval capability remains accessible until the payment is archived, aligning with DECTA's internal regulations regarding payment data retention.

    <!-- Get all payment details and payment status -->

    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:PaymentServer">
    <soapenv:Header/>
    <soapenv:Body>
    <urn:GetPayment>
    <paymentID>${paymentID}</paymentID>
    </urn:GetPayment>
    </soapenv:Body>
    </soapenv:Envelope>

Simple Payments

Simple payments are initiated by calling the web service Request method. These payments involve predefined biller and instrument reference values, as well as a set of mandatory and optional details. Simple payments are categorized into groups based on business functionality.

AUTH

The AUTH scenario serves multiple purposes, including the registration of recurring payments and card data validation, such as “Account Verification” by Visa and “Account Status Inquiry” by Mastercard, without the necessity of sending a financial message.

In this payment scenario, specific details related to recurring payments are mandatory, and the use of airline addendum specific details is not allowed.

During the execution of payments within this scenario, the system will initiate an account verification request. The generation of a recurring payment will only occur when the account verification process has been successfully completed.

    <!-- card check scenario with possibility to save card data -->
    <!-- Step1 -->
    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:PaymentServer">
    <soapenv:Header/>
    <soapenv:Body>
    <urn:Request>
    <billerRef>${billerRef}</billerRef>
    <payinstrRef>${payinstrRef}</payinstrRef>
    <details>
        <item><name>amount</name><value>0</value></item>
        <item><name>ccy_code</name><value>${ccy_code}</value></item>
        <item><name>merchant_id</name><value>${mid}</value></item>
    </details>

    </urn:Request>
    </soapenv:Body>
    </soapenv:Envelope>


    <!-- Step2 -->
    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:PaymentServer">
    <soapenv:Header/>
    <soapenv:Body>
    <urn:Request>
    <paymentID>${payment_id_from_step1}</paymentID>
    <details>
        <item><name>pan</name><value>${pan}</value></item>
        <item><name>expiry</name><value>${exp}</value></item>
        <item><name>cardname</name><value>${name_on_card}</value></item>
        <item><name>client_ip_addr</name><value>${cardholder_ip}</value></item>
        <item><name>cookie_info_id</name><value>${cookie_info}</value></item>
        <item><name>perspayee_gen</name><value>1</value></item>
        <item><name>biller_client_id</name><value>${mid}_${unique_req_id}</value></item>
    </details>
    <confirmed><value>true</value></confirmed>
    <finished><value>true</value></finished>
        </urn:Request>
    </soap-env:Body>
    </soap-env:Envelope>

AUTH_NAME

The AUTH_NAME payment scenario is specifically designed for Account Name Inquiry requests in account verification messages. During the payment execution, system will generate an account verification request that includes Account Name. This request is initiated when account verification is successfully completed. Detail cardname serves as the source for the account owner's name inquiry.

For this payment scenario airline addendum specific details are prohibited.

Account name inquiry is not supported for Mastercard cards.

SMS

Payment scenario for payment execution in SMS mode with optional:

• Recurring payment generation
• Airline addendum specific message generation
• Apple Pay payment generation

Simultaneous use of regular recurring payments and airline addendum specific details is prohibited.

    <!-- SMS Payment -->
    <!-- Step1 -->
    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:PaymentServer">
    <soapenv:Header/>
    <soapenv:Body>
    <urn:Request>
    <billerRef>${billerRef}</billerRef>
    <payinstrRef>${payinstrRef}</payinstrRef>
    <details>
        <item><name>amount</name><value>${amount}</value></item>
        <item><name>ccy_code</name><value>${ccy_code}</value></item>
        <item><name>merchant_id</name><value>${mid}</value></item>
    </details>

    </urn:Request>
    </soapenv:Body>
    </soapenv:Envelope>


    <!-- Step2 -->
    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:PaymentServer">
    <soapenv:Header/>
    <soapenv:Body>
    <urn:Request>
    <paymentID>${payment_id_from_step1}</paymentID>
    <details>
        <item><name>pan</name><value>${pan}</value></item>
        <item><name>expiry</name><value>${exp}</value></item>
        <item><name>csc</name><value>${cvv2}</value></item>
        <item><name>cardname</name><value>${name_on_card}</value></item>
        <item><name>client_ip_addr</name><value>${cardholder_ip}</value></item>
        <item><name>cookie_info_id</name><value>${cookie_info}</value></item>
        <!-- optional recurring/cof registration items -->
        <item><name>perspayee_gen</name><value>1</value></item>
        <item><name>biller_client_id</name><value>${mid}_${unique_req_id}</value></item>
        <item><name>recurring</name><value>${rec_flag}</value></item>
        <item><name>onfile</name><value>${onfile_flag}</value></item>
        <item><name>oboc</name><value>${oboc_flag}</value></item>
        <!-- optional 3D items -->
        <item><name>xid</name><value>${xid_from_MPI}</value></item>
        <item><name>cavv</name><value>${cavv_from_MPI}</value></item>
        <item><name>eci</name><value>${eci_from_MPI}</value></item> 
        <item><name>3ds_protocol</name><value>${3ds_protocol}</value></item> 
        <item><name>3ds_ds_id</name><value>${3ds_ds_id}</value></item> 
    </details>
    <confirmed><value>true</value></confirmed>
    <finished><value>true</value></finished>
        </urn:Request>
    </soap-env:Body>
    </soap-env:Envelope>

QCash

The QCash payment scenario is designed for payment execution and applies to SMS or DMS modes under specific conditions:

• MCC 6051 Cryptocurrency Merchants (Visa, Mastercard): applicable when making payments at cryptocurrency merchants with MCC (Merchant Category Code) 6051, whether using Visa or Mastercard;
• MCC 6211 High-Risk Purchases with Mastercard Cards: It is also applicable for high-risk purchases with Mastercard cards under MCC 6211.

However, for MCC 6211 high-risk purchases with Visa cards and MCC 6211 low-risk purchases with Visa and Mastercard cards, the standard SMS/DMS payment scenarios should be used instead of the QCash scenario.

Starting from 2024 Visa and Mastercard require usage of account funding transactions (AFT) for processing of purchases at cryptocurrency merchants and/or MCC 6211 high risk merchants. See the section Account Funding Transaction Specific Details (AFT) for the usage of AFT.

DMS

The DMS (Dual Message System) payment scenario is tailored for payment execution in DMS mode, offering optional functionalities:

• Recurring payment generation;
• Airline addendum specific message generation.

Please note that the simultaneous use of regular recurring payments and airline addendum specific details is prohibited within this scenario.

Within this payment scenario payments three steps must be executed:

Step 1 - this step is primarily designed for communication fault resistance. During this phase, a request with a minimal set of details is sent to the EBPP (Electronic Bill Presentment and Payment) component for the sole purpose of retrieving the paymentID.
Step 2 - this step is dedicated to fund blocking on the cardholder's account.
Step 3 - this step must be executed after goods or services have been provided to the cardholder. During this phase, the cardholder's account is debited.

    <!-- DMS Payment -->
    <!-- Step1 -->
    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:PaymentServer">
    <soapenv:Header/>
    <soapenv:Body>
    <urn:Request>
    <billerRef>${billerRef}</billerRef>
    <payinstrRef>${payinstrRef}</payinstrRef>
    <details>
        <item><name>amount</name><value>${amount}</value></item>
        <item><name>ccy_code</name><value>${ccy_code}</value></item>
        <item><name>merchant_id</name><value>${mid}</value></item>
    </details>

    </urn:Request>
    </soapenv:Body>
    </soapenv:Envelope>


    <!-- Step2 -->
    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:PaymentServer">
    <soapenv:Header/>
    <soapenv:Body>
    <urn:Request>
    <paymentID>${payment_id_from_step1}</paymentID>
    <details>
        <item><name>pan</name><value>${pan}</value></item>
        <item><name>expiry</name><value>${exp}</value></item>
        <item><name>cardname</name><value>${name_on_card}</value></item>
        <item><name>client_ip_addr</name><value>${cardholder_ip}</value></item>
        <item><name>cookie_info_id</name><value>${cookie_info}</value></item>
        <!-- optional recurring/cof registration items -->
        <item><name>perspayee_gen</name><value>1</value></item>
        <item><name>biller_client_id</name><value>${mid}_${unique_req_id}</value></item>
        <item><name>recurring</name><value>${rec_flag}</value></item>
        <item><name>onfile</name><value>${onfile_flag}</value></item>
        <item><name>oboc</name><value>${oboc_flag}</value></item>
        <!-- optional 3D items -->
        <item><name>xid</name><value>${xid_from_MPI}</value></item>
        <item><name>cavv</name><value>${cavv_from_MPI}</value></item>
        <item><name>eci</name><value>${eci_from_MPI}</value></item> 
        <item><name>3ds_protocol</name><value>${3ds_protocol}</value></item> 
        <item><name>3ds_ds_id</name><value>${3ds_ds_id}</value></item> 
    </details>
    </urn:Request>
    </soap-env:Body>
    </soap-env:Envelope>

    <!-- Step3 - charge amount can be less than hold amount in Step1 -->
    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:PaymentServer">
    <soapenv:Header/>
    <soapenv:Body>
    <urn:Request>
    <paymentID>${payment_id_from_step1}</paymentID>
    <details>
    <!-- optional change of amount -->
        <item><name>amount</name><value>${amount}</value></item>
    </details>
    <confirmed><value>true</value></confirmed>
    <finished><value>true</value></finished>
    </urn:Request>
    </soap-env:Body>
    </soap-env:Envelope>

RECO

After execution, transactions completed during the business day are forwarded to clearing systems. Business day closure should occur at least once every working day. The specific time for business day closure must be agreed upon with DECTA. It is important to note that the use of recurring payments or airline addendum details is strictly prohibited within this scenario. Details returned in the Step 2 response represent technical information accumulated in the RTPS system and do not represent the actual amounts to be settled.

We highly recommend conducting a RECO operation before 01:00 EET (GMT+02:00 Standard Time or GMT+03:00 Summer Time). Any business closings conducted after 01:00 will be processed on the following business day.

Merchants are responsible for the execution of RECO operations, ensuring the timely closure of their business days.

    <!-- RECO - close of business day and reconcile all auths-->
    <!-- Step1 -->
    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:PaymentServer">
    <soapenv:Header/>
    <soapenv:Body>
    <urn:Request>
    <billerRef>${billerRef}</billerRef>
    <payinstrRef>${payinstrRef}</payinstrRef>
    <details>
        <item><name>merchant_id</name><value>${mid}</value></item>
    </details>

    </urn:Request>
    </soapenv:Body>
    </soapenv:Envelope>


    <!-- Step2 -->
    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:PaymentServer">
    <soapenv:Header/>
    <soapenv:Body>
    <urn:Request>
    <paymentID>${payment_id_from_step1}</paymentID>
    <confirmed><value>true</value></confirmed>
    <finished><value>true</value></finished>
        </urn:Request>
    </soap-env:Body>
    </soap-env:Envelope>

REFND

The REFND payment scenario is specifically intended for the execution of refund operations. It is designed for situations where a considerable amount of time (more than 24 hours) has passed since the initial debit transaction.

Unlike some scenarios, REFND does not require a direct reference to the original transaction. RTPS EBPP does not validate the presence of the original debit transaction. This means it is possible to create a refund without any direct link to the initial transaction, as long as the refund amount is equal to or smaller than the original transaction.

If needed, it is possible to refer to the original payment, but it must not be older than 365 days. Data for this purpose has been accumulated since July 17th 2021, for a period of one year, extending the refund period from the previous 45 days to 365 days.

As with other scenarios, the use of recurring payment or airline addendum details is strictly prohibited within the REFND scenario.

REFND transactions can be done offline or online. Online mode is available for Visa and Mastercard cards.

    <!-- Refund - credit cardholder account -->
    <!-- Step1 -->
    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:PaymentServer">
    <soapenv:Header/>
    <soapenv:Body>
    <urn:Request>
    <billerRef>${billerRef}</billerRef>
    <payinstrRef>${payinstrRef}</payinstrRef>
    <details>
        <item><name>amount</name><value>${amount}</value></item>
        <item><name>ccy_code</name><value>${ccy_code}</value></item>
        <item><name>merchant_id</name><value>${mid}</value></item>
        <!-- service detail, wil lbe deprecated in next version of soap integration -->
        <item><name>point_code</name><value>deprecated</value></item> 
    </details>

    </urn:Request>
    </soapenv:Body>
    </soapenv:Envelope>


    <!-- Step2 -->
    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:PaymentServer">
    <soapenv:Header/>
    <soapenv:Body>
    <urn:Request>
    <paymentID>${payment_id_from_step1}</paymentID>
    <details>
        <item><name>pan</name><value>${pan}</value></item>
        <item><name>expiry</name><value>${exp}</value></item>
    </details>
    <confirmed><value>true</value></confirmed>
    <finished><value>true</value></finished>
    </urn:Request>
    </soapenv:Body>
    </soapenv:Envelope>

Account Funding Transaction Specific Details (AFT)

The AFT (Account Funding Transaction) and AFT AA (Account Funding Transaction for Same Person) payment scenarios are tailored for specific debit transaction execution. These scenarios can also function as standalone payment scenarios for:

• SDWO funding transactions, which involve funding before the purchase;
• Funding of crypto-currency merchant account or purchase of crypto-currency (required by Visa and optional by Mastercard);
• Funding of high-risk forex merchant account or purchase of high-risk assets (optional by Visa and by Mastercard);
• Funding of low risk forex merchant account or purchase of low risk assets (optional by Visa and by Mastercard);
• Funding of gaming merchant account or purchase at gaming/gambling merchant (optional by Mastercard).

AFT payment scenario should be used if the sender and receiver are two different private customers. Funding transactions will be coded as FT for Visa cards and F07 for Mastercard cards.

AFT AA payment scenario should be used if the sender and receiver is the same person:

• For Mastercard AFT AA funding transactions the type of funding entity must be specified (detail funding_type) to indicate the correct type of card funding and the type of assets (detail hr_asset, if required). DECTA supports the following AFT account-to-account funding types for Mastercard: F52 (payment account), F61 (SDWO account), and F64 (prepaid and gift cards);
• Detail funding_type is not required for Visa AFT AA funding transactions, but detail hr_asset or crypto should be used for crypto-currency purchases. Funding type FT or LA will be used for AFT transactions with Visa cards.

Recurring is allowed for both AFT scenarios.

For Visa AFT authorisations, only message type 0200 (Single message) authorisation is supported.

Staged Digital Wallet Operator (SDWO) Payments

This scenario is designed for payments within digital wallets, specifically in SMS mode. There are two primary types of operations:

• SDWO funding - digital wallet funding (“before the purchase”);
• SDWO purchase - purchase via digital wallet (“during the purchase” or “back-to-back purchase”).

Recurring payments are allowed within this scenario. This means that customers can set up scheduled or automated payments within their digital wallets for convenience. It is important to note that the use of airline addendum specific details is strictly prohibited within this scenario.

Staged Digital Wallet Operator (SDWO) Payout

This scenario pertains to payout operations conducted within digital wallets, specifically in SMS mode. There are two primary types of payout operations:

• SDWO payout – payout from digital wallet;
• SDWO merchant payout – payout from digital wallet merchant.

Airline addendum specific details, recurring details, and use of a dynamic descriptor are prohibited.

VISA Authorisation Upgrade

When processing a VTS authorisation with token data and cryptogram but without 3D validation, in certain cases, Visa can upgrade the authorisation from non-secure (ECI 07) to secure (alias 3D secure, ECI 05) for:

• VTS authorisations where physical secure element or host card emulation is used for tokenization (see also Apple Pay and PSD2 SCA);
• VTS authorisations where card-on-file token is requested and used by Apple Inc.;
• Account funding transactions (AFT) for any type of VTS token.

These authorisation upgrades have implications for various payment scenarios, including SMS payments, DMS payments, Apple Pay purchases in SMS mode, Apple Pay purchases in DMS mode, and AFT payments.

Merchants are required to include the ECI (Electronic Commerce Indicator) value and TAVV provided by the device-based token requestor in their authorisation requests.

Visa has a process in place to potentially reclassify these transactions as secure e-commerce transactions (ECI 05). This reclassification is based on the successful validation of the TAVV and the type of token used. If a transaction does not meet the criteria for ECI 05 but passes other validation checks, Visa will forward it to the issuer with an ECI 07 (Non-authenticated security transaction) for their approval decision.

Airline Addendum Payments

The core payment execution logic remains unaffected by the inclusion of airline addendum specific details. When these details are included in payment Step 2, RTPS EBPP generates additional internal requests, one for each trip leg. These requests serve the purpose of delivering information to the clearing system.

Airline addendum payment-specific details are categorized into two groups: common details applicable to all trip legs and details specific to each trip leg. The primary determinant for generating airline addendum messages is the "n_legs" parameter. If this parameter is specified, the system will attempt to generate airline addendum messages based on the request details. If it is not specified, the system will not process airline addendum specific details.

Stored card data (see section Recurring Payment) can be used to make irregular airline addendum payments, but it's essential to note that using airline addendum functionality for regular recurring payments is prohibited. Airline addendum data must be supplied by the merchant with each transaction.

Furthermore, the use of airline addendum payments is only possible when an integration project with Visa and/or Mastercard is in progress or opened. This integration is essential to enable and support this specific payment feature.

Tokenized wallet payments

Merchants can use digital wallets such as Apple Pay or Google Pay for the payment processing. In the case of tokenized wallet payment, merchants are receiving token or card data from Apple or Google and must include this data with other payment details in the payment message sent to DECTA.

Apple Pay provides merchants with card token, token cryptogram, and electronic commerce indicator as part of the payment process.

Google Pay provides:

• For the authentication method “CRYPTOGRAM_3DS”, Google Pay provides card token, token cryptogram, and electronic commerce indicator;
• For the authentication method “PAN_ONLY”, Google Pay provides card number and expiry date. “PAN_ONLY” payments initiated by Google Pay must be processed by the merchant as an e-commerce usual manner.

Merchant business website URL and Wallet id must be included in payment details for tokenized wallet payments.

Recurring Payment

Core payment execution, whether in its simplified or advanced form, remains unaffected by the use of recurring payment - specific details. When the provided details are included during the payment's second step, the RTPS EBPP system will subsequently generate recurring payments based on the outcomes of the financial message transmission. Notably, the generation of recurring payments for Person-to-Person transactions necessitates the transmission of a financial message. It is important to highlight that employing both recurring payment and airline addendum details concurrently is prohibited.

Recurring payments are divided into two categories based on where the data is stored: within the DECTA system or on the IPSP side.

Recurring Payment Registration

In straightforward payment scenarios, it is possible to establish a recurring payment without the necessity of transmitting a financial message (as seen in the AUTH scenario type).

Should the requirement to modify recurring payments arise, the process mirrors that of the initial generation of recurring payments. To effect updates in simple payment scenarios, the AUTH scenario type must be used. Within the Step 2 request details, the parameter "perspayee_overwrite" should be passed with a value set to "1".

The functionality is applicable with and without 3D authentication.

Recurring Payment Execution

Initiating payments through the AutoPayment method within the web service triggers recurring payment processes. These processes rely on predefined recurring payment configurations. During payment execution, it is possible to modify specific recurring payments details, such as the payment amount.

Recurring payments can be generated with two execution types:

• Manual Execution - Payments are processed exclusively upon external system requests. Further insights can be found in the Recurring Payment Execution section;
• Manual and Automatic Execution - Recurring payments can occur automatically on a predefined schedule or be triggered by an external system. If it’s specified, the payment will be executed automatically.

Visa and Mastercard recognize two recurring payment types:

• Regular Recurring Payment: Featuring a fixed payment amount and interval;
• Irregular Recurring Payment: Encompassing variable amounts and intervals.

DECTA does not store service location data (details sl_city, sl_region, sl_country, sl_index). Therefore, in instances where payment execution requires different service location details from the merchant's address, these particulars must be supplied by the merchant with each transaction.

Recurring Scenarios

Recurring data stored on the DECTA side and initiated by the merchant

Recurring data stored on the DECTA side and initiated by the cardholder

Recurring data stored on the IPSP side and initiated by a merchant

cof_original_tid detail with valid registration transaction ID must be provided by IPSP/merchant!

Recurring data is stored on the IPSP side and initiated by the cardholder

Cardholder Initiated One-click Payments

In the standard one-click payment scenario, the process unfolds as follows:

• Basic payment attributes are registered as recurring payment. For this purpose, any scenario could be used – AUTH, SMS, QCash, DMS;
• The individual initiating the recurring payment is the Cardholder;
• Recurring payment execution with specific details being passed:
  • recurring=n to indicate that the payment is One-click, not recurring. This will produce correct point code instead of one used for recurring;
  • Payment specific details – amount, csc and other fields, as required by business logic. The functionality is applicable with and without 3D authentication.

Instalment Payments

Merchant Instalments (also known as buy now pay later) payments are similar to recurring payments.

Similar processing logic as in case of recurring registration and execution must be applied. For specific Instalments payment details see ‘Recurring scenarios’ paragraph.

This payment scenario applies only to merchant-processed instalments and does not cover those processed by the issuing and/or acquiring bank. Regarding Visa Instalments Solutions see next chapter.

Visa Instalment Solutions

Effective 19 October 2024, issuers and issuer processors in the United Kingdom must support Visa Instalment Solutions (VIS).

VIS in DECTA processing is supported for SMS, DMS, refunds, return and cancel scenarios. VIS can not be used for account funding (AFT), payouts or recurring payments.

Merchant or the merchant gateway must implement VIS - an API based solution provided by Visa for data exchange regarding instalment payment plans between issuer and cardholder. Information about the agreed instalment payment plan must be included in the payment data sent to DECTA processing. Payments with Visa Instalments can be processed in two ways:

• VIS API integration done on DECTA side: by using the DECTA system, merchants are receiving VIS instalment plan details that must be included in every required Step of the payment, refund, return reversal and cancel scenario;
• VIS API integration done on IPSP side: if using IPSP VIS API solution, merchants must use detail recurring with value ’I’ and detail inst_plan_id with Plan Registration System Identifier received in VIS API response. These both details must be used also in refund, return and cancel scenarios in case of payment cancellation.

Payouts

Payouts encompass various scenarios for executing credit operations, each designed for specific purposes.

Furthermore, payment card organizations enforce particular mandates on the payouts to ensure compliance with regulations and standards in different regions.

Online Gaming Payouts (OG)

The OG scenario is designed for executing credit operations in a straightforward manner. It is intended for specific use cases, including gambling payouts for both Visa and Mastercard cards, as well as Mastercard Payment transactions.

The use of recurring payment functionality is not allowed within this scenario. The inclusion of airline addendum specific details is also prohibited.

Account to Account Payout Specific Details (A2A)

The A2A scenario is designed for executing credit operations, allowing cardholders or companies to transfer money from their own account to another card account. This scenario ensures a seamless fund transfer process.

Recurring payments are not supported within this scenario.

Funds Transfer Specific Details (FT)

The FT scenario is designed for simple debit and credit operations, specifically for Visa cards. This scenario is ideal for cardholders or companies looking to transfer funds from a Stored Value Digital Wallet (SVDW) account to their card account.

The use of recurring payment functionality is not allowed within this scenario.

Payroll & Pensions Disbursements Payout Specific Details (PD)

The PD scenario is a simple payment scenario designed for the execution of credit operations. It is intended for specific use cases, including payments to independent contractors working for temporary staffing agencies or directly with employers, as well as pension payouts.

The use of recurring payment functionality is not permitted within this scenario.

Person to Person (P2P) Payments and Business to Person (B2P) Payments

The P2P and B2P payment scenarios are initiated by calling a web service Request method with predefined switchingID and autoSwitch values, along with a set of mandatory and optional details. These scenarios are primarily used for initiating Mastercard MoneySend payment transactions and Visa Direct Original Credit Transactions.

Once a P2P or B2P transaction is successfully completed, it cannot be reversed. The use of recurring payment functionality is prohibited within these scenarios.

<!--Full P2P -->
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:PaymentServer">
<soapenv:Header/> 
<soapenv:Body> 
    <urn:Request> 
        <language>en</language> 
        <switchingID><value>{{switchingID}}</value></switchingID> 
        <details>
            
            <!-- mandatory items -->
            <item><name>pan</name><value>{{v1}}</value></item>
            <item><name>expiry</name><value>{{v1_exp}}</value></item>
            <item><name>pan2</name><value>{{v1}}</value></item>
            <item><name>expiry2</name><value>{{v1_exp}}</value></item>
            <item><name>amount</name><value>{{amount}}</value></item>
            <item><name>ccy_code</name><value>{{ccy_code}}</value></item>
            <item><name>client_ip_addr</name><value>1.1.1.1</value></item>
            <item><name>merchant_ext2</name><value>{{merchant_ext2}}</value></item>
            <item><name>cardname</name><value>Name Surname</value></item>

            <!-- Enhanced p2p items -->
            <item><name>client_address</name><value>{{client_address}}</value></item> 
            <item><name>client_city</name><value>{{client_city}}</value></item>
            <item><name>client_name</name><value>Name Surname</value></item>
            <item><name>client_postal_code</name><value>LV1000</value></item>
            <item><name>client_birth_date</name><value>01012000</value></item>
            <item><name>client_country_code</name><value>428</value></item>
            <item><name>client_state_code</name><value>AB</value></item>
            <item><name>client_account_number</name><value>{{client_account_number}}</value></item>
            <item><name>client_account_type</name><value>{{client_account_type}}</value></item>
            
            <item><name>recipient_country_code</name><value>428</value></item>
            <item><name>recipient_birth_date</name><value>02021999</value></item>
            <item><name>recipient_name</name><value>Name Surname</value></item>
            <item><name>recipient_account_number</name><value>{{recipient_account_number}}</value></item>
            <item><name>recipient_account_type</name><value>{{recipient_account_type}}</value></item>
            <item><name>recipient_city</name><value>Riga</value></item>
            <!-- Mandatory airline items -->
            
            <!-- Optional airline items -->
            
            
        </details>
        <autoSwitch>1</autoSwitch>
    </urn:Request> 
</soapenv:Body> 
</soapenv:Envelope>

Payout Specific Mandates

When processing payout transactions, it is essential to adhere to specific mandates imposed by payment card organisations. These mandates ensure compliance with regulations and standards across different regions. Here are the key mandates for various scenarios:

Visa Mandates for Cross-Border Payouts and Account Fundings to Canadian Cardholders - merchants must provide the recipient's address when conducting cross-border payouts or account fundings to Canadian cardholders.

Visa Mandates for India, Bangladesh, Argentina, Egypt, Chile, Colombia and Mexico Recipients - for recipients in India, Bangladesh, Argentina, Egypt, Chile, Colombia and Mexico, merchants must provide information about the purpose of payment. The "Purpose of Payment" is a free-text field, but in India, Bangladesh, and Argentina, specific purpose of payment codes should be used as required in the respective country. In Egypt, Chile, Colombia and Mexico, a text message should be provided as part of the purpose of payment either as free text or ISO 20022 external purpose code.

Mastercard Mandates for Client and Recipient Account Information - Mastercard mandates that merchants provide information about both the client and recipient account types and account numbers.

Mandates for Canada and the USA - for cross-border payouts involving Canada and the USA, merchants must provide the state/province code as part of the client and/or recipient address data.

Visa mandates for Cryptocurrency Wallet Disbursements - Visa requires merchants to include the cryptocurrency flag (detail crypto) when disbursing funds from cryptocurrency wallets. This requirement applies to all business-to-card type payouts, including funds transfer (FT), SDWO payout (WT), and B2P payments (FD).

Mastercard Requirements for Cryptocurrency Disbursements - Mastercard mandates that merchants include the cryptocurrency flag (detail crypto) when disbursing funds that have originated from, or could reasonably be assumed to have originated from, the sale of cryptocurrency. This requirement specifically applies to funds transfer (FT) payouts.

Visa Payout (OCT) Authorisations - for Visa payout (OCT) authorisations, only message type 0200 (Single Message) authorisation is supported