In October, Visa released a new requirement which requires a new recurring indicator and original transaction ID for recurring transactions. Discover will soon follow suit with similar requirements in an effort to enhance the integrity of recurring authorizations for digital wallets. What changes are merchants required to make to their integration in order to stay in compliance?
If a merchant is processing recurring transactions on the Vantiv eCommerce (Litle) platform, please see the following guidance:
Merchants who do not implement these changes will begin to see Visa recurring transactions for digital wallets decline.
The new elements are currently available in schema versions V8.30, V9.10, and V10.5, so merchants can code for their use now. For merchants using the recurring engine, the changes will be activated after the January kit install (January 5th, 2017).
Here’s what merchants need to do:
2. Code for 3 new additional fields:
<processingType> set to initialRecurring, submitted on the first transaction in the recurring stream along with the Cryptogram
<originalNetworkTransactionId> For Visa (currently enforced) and Discover (future release), the XML response to the merchant will include this value in order to create a reference to the original transaction. Each subsequent recurring transaction will need to include this field
The merchant will need to retain this value, which will be used when they submit all subsequent transactions in the recurring st
<originalTransactionAmount>, the amount from the initial transaction in a recurring stream. This is a requirement for Discover transactions, but can be included in the schema for all, as it will not reject.
Additional Information:
The additional three XML elements noted above for immediate use in production may be submitted within the XML request for all payment types. We will ignore the additional elements for the non-Visa payment types and submitting such will not cause the transaction to decline.
In the XML Request for Auth or a Sale for the initial transaction, the processingType would be placed in the last line prior to the </authorization> or sale </sale> and </litleOnlineRequest>. <xs:element name="processingType" type="xp:processingTypeEnum" minOccurs="0"/>
In the XML Request for Auth or Sale for all subsequent/recurring transactions, the originalNetworkTransactionId would be placed in the 2nd to last element prior to the </authorization> or sale </sale> and </litleOnlineRequest>.
<xs:element name="originalNetworkTransactionId" type="xp:string30Type" minOccurs="0"/> and <originalTransactionAmount> is the last element. Please see the attached BTW...all of this is visible in the V10.5 schema.
If a merchant is processing on the Vantiv Core/RAFT/ISO interface we will have an updated specification here in January.
If a merchant is processing recurring transactions on the Vantiv eCommerce (Litle) platform, please see the following guidance:
Merchants who do not implement these changes will begin to see Visa recurring transactions for digital wallets decline.
The new elements are currently available in schema versions V8.30, V9.10, and V10.5, so merchants can code for their use now. For merchants using the recurring engine, the changes will be activated after the January kit install (January 5th, 2017).
Here’s what merchants need to do:
2. Code for 3 new additional fields:
<processingType> set to initialRecurring, submitted on the first transaction in the recurring stream along with the Cryptogram
<originalNetworkTransactionId> For Visa (currently enforced) and Discover (future release), the XML response to the merchant will include this value in order to create a reference to the original transaction. Each subsequent recurring transaction will need to include this field
The merchant will need to retain this value, which will be used when they submit all subsequent transactions in the recurring st
<originalTransactionAmount>, the amount from the initial transaction in a recurring stream. This is a requirement for Discover transactions, but can be included in the schema for all, as it will not reject.
Additional Information:
The additional three XML elements noted above for immediate use in production may be submitted within the XML request for all payment types. We will ignore the additional elements for the non-Visa payment types and submitting such will not cause the transaction to decline.
In the XML Request for Auth or a Sale for the initial transaction, the processingType would be placed in the last line prior to the </authorization> or sale </sale> and </litleOnlineRequest>. <xs:element name="processingType" type="xp:processingTypeEnum" minOccurs="0"/>
In the XML Request for Auth or Sale for all subsequent/recurring transactions, the originalNetworkTransactionId would be placed in the 2nd to last element prior to the </authorization> or sale </sale> and </litleOnlineRequest>.
<xs:element name="originalNetworkTransactionId" type="xp:string30Type" minOccurs="0"/> and <originalTransactionAmount> is the last element. Please see the attached BTW...all of this is visible in the V10.5 schema.