Skip to content

1 - General Notes

Rapyd Acquiring System enables card payments in a wide range of currencies. Merchants can enjoy the benefits of choosing settlement currencies to designated bank accounts in their home country or in the location in which their business is conducted. Rapyd can offer settlements in any currency supported by Visa EU and MasterCard but is currently set up with and using USD, EUR, GBP, CHF, DKK, ISK, NOK, SEK, CAD, HKD, JPY, PLN & AUD. For secure e-commerce (Verified by Visa & SecureCode), Rapyd offers 3DS Card Verification function in Rapyd Gateway. Merchants (or processors) who wish to use another certified Merchant Plug-In will be expected to contact us in advance and participate actively in the Product Integration Testing (PIT).

Overview

Important

01:00 is the cut-off time for the processing day. All other cycles are subject to change.

1.1 - Current Release Notes - New Functionality

1.1.1 - Automatic Fuel Dispenser (AFD) functionality

Support for a new message type for AFD has been added, for more information on AFD see Authorization Spec - 4.9.

1.1.2 - ATM functionality

A new Transaction Code (see Chapter 4.1.4) and 4 new Transaction Types (see Chapter 7.6 and Chapter 7.7) have been added to support ATM functionality.

Important

Processing of Cash Disbursement transactions is only available in the Icelandic domestic market at this time

1.1.3 - New Settlement Keys

New settlement keys for fees have been added to chapter 4.2.5.

Overview of new keys and changes:

  • AUTHFEE - Authorization Fee
    • This key will replace previous TRFSAG and TRFUAG keys
  • CNPFEE - Card Not Present Fee
  • EGMFEE - Ecom Gateway Monthly Fee
  • EGTFEE - Ecom Gateway Transaction
  • MMSFEE - Minimum Monthly Service Charge
  • MOBFEE - Mobile Airtime Fee
  • MONTHC - Monthly Fee Credit
  • MONTHD - Monthly Fee Debit
  • MONTHM - Monthly Fee Mixed
  • PCMFEE - PCI Fee
  • POSALL - POS Rental Fee
  • PRAFEE - Pre-Authorization Fee

1.2 - Previous Release Notes - Reminders

1.2.1 - New Dispute Reason Codes for Visa (VCR)

Visa has implemented a new solution for dispute resolution called Visa Claims Resolution (VCR). The intent of Visa was to simplify the dispute resolution process, one of the biggest changes facing the customer is the consolidation of legacy reason codes, there are now four main Dispute Categories:

  • 10 – Fraud
  • 11 – Authorisation
  • 12 – Processing Error
  • 13 – Consumer Dispute

Each category is further subdivided into Dispute Conditions, a complete list of the new Reason Codes and mapping to the old Reason codes can be found in Chapter 8.2.

The new format of the Reason Code and Dispute Condition will be XX.YYZ. As a result, the format of the Chargeback File (.cbf) has been modified, the Reason Code field is now eight (8) characters long to accommodate the new format. The fields following the Reason Code field will shift to the right as a result.

Note that customers will not receive the new Chargeback File format unless they explicitly subscribe to it. Customers who are not ready to receive the new format will receive the old reason codes mapped from the new Dispute Category and Dispute Condition Code. Please contact Customer Support for further information.

1.2.2 - New Visa Fraud Types

Visa has introduces new Fraud Types which will appear in the .frf files sent to customers. The specification has been updated with information regarding those new Fraud Types Chapter 5.2.3.

1.2.3 - Transaction LifeCycle ID in recurring transactions

For recurring Visa transactions merchants should store the Transaction LifeCycle ID (see TransLCID in Authorization Spec - 3.1.4) from the first transaction (received in the 0110 response message of the first transaction) and send the Transaction LifeCycle ID in all subsequent 0100 messages (transaction types: 50, 12, 5A). This will increase the likelihood of Issuers approving subsequent recurring messages.

1.2.4 - Zero Amounts are rejected in Clearing

If the Transaction Amount in a Financial Transaction is zero in the Settlement Currency it will be rejected by VAS. For example, the following Financial Transactions would be rejected:

  • Merchants Settlement Currency is USD and Financial Transaction is 0.00 USD.
  • Merchants Settlement Currency is USD and Financial Transaction is 0.01 SEK
    • The 0.01 SEK will be converted to 0.00 USD in Settlement, thus rejected.

Users will see the rejected Financial Transactions in the DCF with error code 2071 (“Refund amount below allowed threshold”) or an existing error code 2025 (“Transaction amount must not equal zero”).

1.2.5 - Merchant Verification Value

Merchant Verification Value is assigned by Visa to identify Merchants that participate in specific programs, for example Staged Digital Wallet Operators (SDWOs). Merchants offering staged digital wallet services should apply for an MVV if they have not already been assigned an MVV (contact Rapyd Customer Care). Merchant should send the MVV in Additional Data tag 04 as described in Authorization Spec - 3.1.6.

1.2.6 - Wallet ID

Authorizations submitted using wallets on the MasterCard Digital Enablement Service (MDES) or Masterpass platform should use the appropriate Wallet ID. Merchants should send the Wallet ID in Additional Data tag 05 as described in Authorization Spec - 3.1.6.

1.2.7 - Notice regarding preauthorizations

All users of the Rapyd Acquiring System (VAS) must correctly distinguish between a full authorization and a preauthorization. By default all authorizations are coded as full authorizations (TransStatus = ‘N’) if not otherwise specified by the TransStatus Data Element Authorization Spec - 3.1.4. Use TransStatus = ‘P’ for preauthorizations. Starting 1st of June 2017 users will be subject to fees if they incorrectly code pre-authorizations as full authorizations. Further details will be sent to all affected parties. Note that this currently applies only to MasterCard transactions.

For clarification:

  1. An authorization should be coded as a full authorization if the authorized amount is the final Transaction Amount charged to the cardholder for a given business transaction. That is, the amount presented in clearing is the same as the amount in the authorization. A full authorization should be cleared within four calendar days of the authorization date. A full authorization should not be cancelled.
  2. An authorization should be coded as a preauthorization if one of the following conditions apply:
    • The authorized amount is an estimated amount charged to the cardholder which may change during the life cycle of the transaction. For example, an authorization is sent to hold funds for two items ordered online by the cardholder. The merchant only has one of the items in stock and sends a clearing message for a lower amount than the authorized amount.
    • The transaction may be finalized via other payment methods at a later time (for example, a preauthorization may be sent when a cardholder checks into a hotel to hold funds as a guarantee of payment but the cardholder may choose to pay for his room at check out with cash, in this case the original authorization should be cancelled). A preauthorization should be cleared within 27 calendar days of the authorization date.

Please note that other preauthorization scenarios are not supported yet, for example partial reversal of a preauthorization amount or incremental preauthorizations.

1.2.8 - Notice regarding Stop Payment Order response

When the user of VAS receives a Stop Payment Order authorization response, he must do as instructed and may not send a subsequent authorization related to the same transaction. Users that continue to send authorizations for the same transaction after having been instructed to Stop Payment Order will be subject to fees for each authorization sent after having received the Stop Payment Order response. This will take effect on the 1st of June 2017.

For clarification: if the authorization response contains the values R0, R1 or R3 in the ResponseCode Data Element (applicable to recurring Visa transactions), the Issuer has received a Stop Payment Order request from the cardholder, or the cardholders account has been closed, and the Issuer will not approve any subsequent authorization requests. See Authorization Spec - 3.1.4 and Authorization Spec - 3.3.4 for further information regarding the ResponseCode Data Element and ResponseCode values.

1.2.9 - Additional Data: Electronic Commerce Indicator

A new TLV tag has been added for token based transactions (i.e. via digital wallet providers using cloud-based payment tokens, for example AndroidPay), cf. Authorization Spec - 3.1.6.

1.2.10 - Merchant Name / Merchant City

These two fields are defined as “an” i.e. alphanumeric, cf. Authorization Spec - 3.1.2. This generally means: A-Z, a-z (plain ASCII only) and 0-9. However, Merchant names sometimes contain special characters and the Merchant City field is sometimes used to send the Customer Support telephone number; therefore, space (ASCII 32) + several basic ASCII punctuation and symbol characters are also allowed i.e. ASCII 39 - 47 (Unicode U+0027 to U+002F: ' ( ) * + , - . / ).

1.2.11 - TransLCID

This field was initially announced in 15.Q2 and implemented in 15.Q3.

Transaction LifeCycle ID – a unique ID assigned by card schemes and defined as:
Visa: Field 62.2 (TID - Transaction Identifier), Format: n 15
MasterCard: DE63 (pos.1-9) + DE15 (of the auth. response, later sent to clearing as Transaction LifeCycle ID in DE63). Format: an 13

Rapyd will send this field back in 0110 response messages and Processors/Merchants should include them in 0400 messages, cf. Authorization Spec - 3.1.4. LifeCycle ID is required in 0400 reversals and in clearing files for all on-line authorized transactions.