AnsweredAssumed Answered

Impact on Visa changes on Apple Pay recurring payments

Question asked by gjsissons on Aug 12, 2016
Latest reply on Dec 7, 2016 by tony.rose@airwaze.io

Like • Show 0 Likes0
Comment • 3

skaraivanov recently explained how merchants using Apple Pay should handle recurring payments with Vantiv's eCommerce (Litle) platform.

As Stefan explains:

Merchants should set orderSource to “applepay” on the first transaction and to “recurring” on the subsequent recurring transactions. In October, Visa is changing how they do this, making it more secure. On the first transaction, Visa will start sending back an ID, which merchants will get in Vantiv’s transaction response. Merchant will then have to pass in that ID in the recurring transactions.

Customer question: Is the new recurring rule specific for Visa only or does it apply to MasterCard transactions as well? Also, given the change is to take effect in October, when will the details be available in the Vantiv ecom Apple Pay spec, the sooner the better.

Thank you!

tboumil Nov 17, 2016 9:09 AM

Correct Answer

The new rules/methods are required by Visa and Discover in April. They are supported by both card brands now; however, we will not have the necessary code in place until the January kit install (on or about January 5, 2017). Having said that, the new elements are already in schema versions V8.30, V9.10, and V10.5, so you could code for their use now and activate the new flow after the January kit install.

At this time, neither MasterCard, nor American Express have made these or similar changes.

See the reply in context

No one else had this question

Outcomes

mcafiero Nov 10, 2016 2:51 PM

tony.rose@airwaze.io wondering if you have any insight so that we can mark this as answered.

Thanks,

Mark

Actions

tboumil Nov 17, 2016 9:09 AM

At this time, neither MasterCard, nor American Express have made these or similar changes.

1 person found this helpful

Actions

tony.rose@airwaze.io Dec 7, 2016 11:56 AM

Visa and Discover Recurring Enhancements for Digital Wallet Transactions

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.

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:

Upgrade XML for this new feature. This will require merchant to use pre-live to submit one of each payment/transaction types they currently support for their business to certify to the new XML version. There is no test in pre live for Visa Recurring for digital wallets.
Code for 3 new additional fields:
1. <processingType> set to initialRecurring, submitted on the first transaction in the recurring stream along with the Cryptogram.
2. <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

i. The merchant will need to retain this value, which will be used when they submit all subsequent transactions in the recurring stream

3. <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.

Actions

3 Replies

mcafiero Nov 10, 2016 2:51 PM
Mark Correct
Correct Answer
tony.rose@airwaze.io wondering if you have any insight so that we can mark this as answered.
Thanks,
Mark
Like • Show 0 Likes0
Actions
tboumil Nov 17, 2016 9:09 AM
Unmark Correct
Correct Answer
The new rules/methods are required by Visa and Discover in April. They are supported by both card brands now; however, we will not have the necessary code in place until the January kit install (on or about January 5, 2017). Having said that, the new elements are already in schema versions V8.30, V9.10, and V10.5, so you could code for their use now and activate the new flow after the January kit install.

At this time, neither MasterCard, nor American Express have made these or similar changes.
1 person found this helpful
Like • Show 0 Likes0
Actions
tony.rose@airwaze.io Dec 7, 2016 11:56 AM
Mark Correct
Correct Answer
Visa and Discover Recurring Enhancements for Digital Wallet Transactions

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.
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:
Upgrade XML for this new feature. This will require merchant to use pre-live to submit one of each payment/transaction types they currently support for their business to certify to the new XML version. There is no test in pre live for Visa Recurring for digital wallets.
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
i. The merchant will need to retain this value, which will be used when they submit all subsequent transactions in the recurring stream
3. <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.
Like • Show 0 Likes0
Actions

Impact on Visa changes on Apple Pay recurring payments

Outcomes

Related Content

Recommended Content