schemeReferenceID

schemeReferenceID

schemeReferenceID_REST

Important note: dummy SchemereferenceIDs expire end of October 2022

If you as a merchant still use the dummy SchemereferenceIDs issued by the card brands, these must be converted / updated by 01.11.2022.

This means that your customers must be requested to update their card data and, in addition, a 3DS authentication is mandatory. For this process the following options are available to you, which you can send to your customer by creating a payment link or customers are requested to do so in the shop via a separate function.

Transaction including reservation of an invoice amount X

If you want to update/convert to a valid SchemereferenceID during a regular payment, i.e. the customer should also be charged for an amount X, use the standard credit card interfaces (...payssl.aspx or ...paynow.aspx).Important here is that the JSON object CredentialOnFile must be initialized as CIT and initial=true. This makes a 3DS challenge mandatory and the SchemereferenceID is generated based on this and can be used as MIT for further subsequent collections.

Card verification - 0.00€ transaction

If you want to update/convert to a valid SchemereferenceID for an account verification (check the card data at the bank with a 0.00€ transaction), please also use the standard credit card interfaces (...payssl.aspx or ...paynow.aspx). Here also it is important that the transaction is initialized with the JSON object CredentialOnFile as CIT and initial=true. This makes a 3DS challenge mandatory and the SchemereferenceID is generated based on this and can be used as MIT for further subsequent collections.

In addition, in this case please also send the key value pair parameter AccVerify, this will trigger a 0.00 transaction downstream.

Common information

The SchemereferenceID is a unique transaction identifier provided directly from the card schemes like VISA and MC in order to uniquely reference a transaction in the whole payment ecosystem. It was introduced initially by VISA in accordance to their Framework specifications like COF (Credential On File) and MIT (Merchant Initiated Transactions), relevant to use cases involving transaction types such as Recurring, UCOF (MIT), Incremental, Delayed Authorization, Resubmission etc.

With the release of EMV 3DS specifications it came as a requirement also for MasterCard to make use of such a unique identifier which they called “traceID” or “grandfathering ID”. The logic behind it, is that the Issuer could rely on this identifier to link the initial payment with all the subsequent ones related to a standing order in a COF or MIT regime. This will allow the Issuer to apply different transaction rules (i.e. no CVV/CVC, no additional authentication in EMV 3DS) for all the subsequent payments.

In the current situation for Mastercard/Maestro transactions on which the initial payment (Establishment of an Agreement) has been put in place prior to enforcement date of the regulation, merchants have not been provided with the “” in authorization responses.

Computop will require those merchants dealing with the above use cases to align with their acquirer on the usage of the card-scheme approved static value "grandfathering" in all the subsequent (COF/MIT) transactions.

For Initial payments (Establishment of an Agreement) after enforcement date of the PSD2 regulation the merchants must save the “schemeReferenceID” value provided in the response and submit it to Paygate in all the subsequent payments related to that Initial agreement. As for VISA the “schemeReferenceID” will be the equivalent of the previous Paygate parameter “TransactionID” that the merchants are currently submitting in accordance to COF & MIT Frameworks.