Closed ex5 closed 3 years ago
👋 @anka-sirota please contact Support, they will assist in troubleshooting this issue with you.
Were you able to figure this one out? We are experiencing the same issue @ex5
@introvert Braintree support had eventually helped with figuring this out, yes. The gist of it was that we had implemented recurring transactions incorrectly.
The fix was passing verify_card: false
when payment method is created to stop 3DS authentication from being consumed, extracting that authentication and storing it, in case first recurring transaction happens in absence of the customer, and then passing that authentication with a source: recurring_first
sale()
call and source: recurring
for subsequent transactions with the same payment method.
This is based on the following suggestion offered by support:
If you do have a recurring model outside of Braintree's recurring billing engine, you would follow the steps above, but add the
transaction_source
option set torecurring_first
in that initial customer present transaction. For subsequent transactions you would pass the transaction source option asrecurring
. Exceptions would apply for recurring transactions using a payment method that has been vaulted prior to September 14, 2019. ... It sounds like you need to be able to provide SCA for transactions that are initiated when the customer is not present, is that correct? If so, I'd like to recommend a potential flow.
- Tokenize customer's payment information, generating a payment method nonce
- Pass that nonce to verifyCard, receiving back a 3DS-enriched nonce. You'll then want to query that nonce and save the three_d_secure_info.three_d_secure_authentication_id from the result in a local database.
- Vault payment method using 3DS nonce, being sure not to use Card Verification (alternatively, pass verify_card as false in your PaymentMethod: Create request.) This is to prevent the SCA acquired in the previous step from being consumed in an authorization.
- When the customer's order to ready to be charged, your integration can make a Transaction: Sale request, specifying the three_d_secure_authentication_id from your local database and the appropriate transaction_source. This ensures that SCA is presented at authorization and 3DS information is populated on the Transaction.
This flow is especially useful because it allows you to store and provide SCA on a future transaction for up to 90 days. ... The three_d_secure_authentication_id value is single use, meaning it should only be passed on the
recurring_first
transaction. Any subsequentrecurring
orunscheduled
transactions would then be out of scope of PSD2 and that three_d_secure_authentication_id is no longer needed on these calls.
General information
Issue description
We are having an issue with 3DS implementation for a platform that uses recurring transactions (no Braintree subscriptions) and DropIn UI. The 3DS in DropIn UI appears to work, a couple of customers reported that they've passed through authentication without any errors, however
sale()
calls using payment methods created with the nonces returned by DropIn still fail with "Authentication Required".The way it's implemented is as follows:
threeDSecure: true
;payment_method_nonce
,device_data
and"verify_card": True
are passed topayment_method.create
and payment method token is stored;However, transactions are still failing with "Authentication Required" for some EU-based customers even though they've passed the authentication process successfully. Please advise on why the 3DS enriched nonces appear to be lost and how can this be fixed on our side.