I followed Braintree tutorial to upgrade to 3DS2: https://developer.paypal.com/braintree/docs/guides/3d-secure/migration/javascript/v3
Everything works fine for sandbox, but after swithing to production, lookup request (url something like https://api.braintreegateway.com/merchants//client_api/v1/payment_methods//three_d_secure/lookup) fails with following result inside response:
threeDSecureInfo: {
status: "lookup_error",
liabilityShiftPossible: false,
liabilityShifted: false
...
}
This lookup response is returned after hosted fields should be tokenized and bank verification should take place with custom UI to verify card.
With 3DS1 we ditn't have any problems and cards were verified.
Any help is appreciated.
Thanks.
3DS is enabled in sandbox automatically to merchants but will have to contact BT to enable in production. There's usually going to be a cost involved per transaction.
In sandbox, 3D Secure is automatically enabled for all merchants.
In production, 3D Secure is not automatically enabled in production
accounts and is only compatible with certain Braintree configurations
in specific regions. Contact us if you're interested in 3D Secure.
https://developer.paypal.com/braintree/docs/guides/3d-secure/configuration
Related
When would you choose confirmCardPayment in the front end and when would you choose paymentIntent.Confirm in the backend?
currently our app allows you to checkout as guest, save a credit card if you are not a guest or use a saved card.
All of these flows work without confirmcardpayment on the frontend and without the paymentintent.confirm on the backend
I'm guessing there will be a time where a card payment requires extra authentication and that is when we need to either confirm in the front end or conifrm in the backend? (Also, when/why would a card require extra authentication? New to this space and looking to learn)
Our code pretty much follows this: https://github.com/stripe-samples/saving-card-after-payment/blob/master/without-webhooks/server/go/server.go
PS: The TLDR from the above link is:
Front end:
Creates a paymentmethod with a given card or saved card.
Sends POST /pay API to backend
Backend:
Receives API (validates if user is auth or not - in our case)
Creates a payment intent to be sent to stripe with paymentmethodID from frontend AND customerID gotten from our backend (Stripe's customer id that we created beforehand)
Stripe returns us the paymentmethod with status.
No confirmation on either front.
If same payment method tries to get used for another customer, fails.
If same payment method gets used for same customer (Saved card behavior) it works.
I'm guessing there will be a time where a card payment requires extra authentication and that is when we need to either confirm in the front end or conifrm in the backend?
You need to do this on the frontend because of customer authentication yes. Confirming on the frontend attempts the payment, and the Stripe JS library will also present any additional UI needed like the customer's bank's 3D Secure authentication page.
That is also important for accepting other types of payment methods(which you should, as having more local payment methods in your checkout flow increases customer conversion). E.g., payments using iDEAL require a redirect to the customers bank which again is handled on the client side. https://stripe.com/docs/payments/ideal#payment-flow
(Also, when/why would a card require extra authentication? New to this space and looking to learn)
Pretty much any transaction in Europe and the UK requires 3D Secure authentication right now, and it's only becoming more prevalent worldwide
https://stripe.com/docs/strong-customer-authentication
https://stripe.com/docs/payments/3d-secure
https://support.stripe.com/questions/strong-customer-authentication-sca-enforcement-date
Our code pretty much follows this
The Github link/flow you linked is an alternative way of using Stripe where you attempt the payment on the backend and then need to do a round-trip if authentication is required , but it's generally preferred to use client-side confirmation as it's more scalable for accepting other payment methods. See the notes on
https://stripe.com/docs/payments/accept-a-payment-synchronously
I'm using Braintree for my site's payments and it works well except that when a user has selected a payment card from its chrome's history and he/she mistakenly inputs a wrong CVV the Braintree will fail the transaction (when trying to verify) but it saves the credit card and the user cannot edit him/her mistake, and only thing he/she can is to delete the CC using the Braintree's vault manager and re-enter again!
Question:
How can I make drop-in to edit the selected card when the card's verification fails?
Full disclosure: I work at Braintree. If you have any further questions, feel free to contact support.
Vault manager does not allow the ability to edit the CVV (or any values) on the cards saved to the Vault. I can certainly pass this along as a future feature request.
This does not sound like the expected behavior if you are verifying prior to Vaulting in production and have CVV rules enabled to reject if the CVV does not match. If you are running into this error in production, please reach out to our Support team with an example. If this is in sandbox, please ensure you are using a test CVV to trigger the desired response.
I'm developing an application with react native and I am using this library
https://github.com/tipsi/tipsi-stripe in order to use Google Pay with stripe integration.
I already linked the test key from stripe and the merchant Id from play store.
I have a serious issue though. After running the app, when the Google Pay popup form opens,
i get the Google Pay dialog but with a message
"Unrecognized app. Please make sure you trust this app
before proceeding".
However when I enter a test card and press continue I get an additional error that says
Transaction declined: invalid payment method. [OR-CCSEH-05]
I would appreciate any help.
See image below
When testing Google Pay, you actually use real credit cards. That said, I'd be doubly positive you've got your environment set to use Test Mode in Google Pay. Outside of Tipsi, you'd usually set that with the WalletConstants.ENVIRONMENT_TEST constant. Hope that helps!
i've contacted google regarding this case, as i've been facing similar one and upon it's inspection i've received the following reply:
Thanks for being Patient. I apologize for the inconvenience caused.
Upon checking, I understand that you're unable to add testing cards. I would like to inform you that testing cards can't be added to Google Payment profile as payment Method.
Thanks!
upon further investigation by Stripe it self i've been assured:
For a bit of context on how Google Pay works to test payments. When you’re using your test mode API keys, the actual details of the card are ignored, and they get replaced with the Stripe 4242 test card. To test authentication you will not be able to add the test cards to your Google Pay account however there is a work around for this, you add our 3DS test cards to Chrome and use the PaymentRequest button with them (making sure to choose them, and not Google Pay itself). Unfortunately there is no direct method to testing this in your the app.
so setting WalletConstants.ENVIRONMENT_TEST at 5th step of their tutorial should be sufficient and then use your real card.
https://developers.google.com/pay/api/android/guides/tutorial
I'm currently integrating Squareup APIs for a project. We have a developer account and a merchant account. When I try to test the integration and test payment using Squareup payment form I am getting this error.
{"errors":[{"category":"PAYMENT_METHOD_ERROR","code":"INVALID_CARD","detail":"Invalid card number."}
When I try to use merchant terminal to charge, i'm getting card invalid error page.
Test cards. https://docs.connect.squareup.com/testing/test-values
How can I test credit card processing with test cards?
The way to view sandbox transactions is to call the ListTransactions endpoint with your sandbox credentials to get a sandbox transaction report. Only live transactions will be visible on your Square Dashboard.
To test the full extent of our APIs you'll need to test in production. While there’s not currently a way to delete test transactions, you can definitely process a refund instead. It won’t remove the transactions from your history, but refunding the transaction will balance your books. If you’re not familiar with processing refunds, visit our Support Center for step-by-step instructions.
We're constantly working on adding more features to sandbox. I'll be sure to share your thoughts with the appropriate teams.
We are upgrading our SagePay protocol from v2.23 to 3.0 to support surcharge fees. In v3.0 transaction registration post there are CreateToken and StoreToken which was not in the earlier version. What is the reason for create and store tokens? I went through the document but couldn't find a clue.
The link provided in the above post links to advice by one of our Sage Pay Partners so take a look at it.
Token allows shoppers the option of storing their card details (as a token) to their account on the payment page during their first purchase instead of having to set it up manually afterwards. Single click purchases for repeat customers will become much simpler and quicker to set up.
To view the Token Guide go to here, scroll to the bottom of the screen and select the Download the Documents option within your preferred method of integration (server, server inframe, direct). Within the guide it explains creating and storing a token.
If this is a service you would like enabled on your Sage Pay account our New Business team are available 0900-1800 on 0845 111 4466. Prices for Token are available via here. If you have any other questions, our 24/7 Support team can assist to on 0845 111 4455.
Sage Pay Support.
I believe this is related to their token system, allowing you to store and send card details as a token.
If you don't use their token system you don't need to worry about it.
Sage Pay have destroyed their content recently so it's hard to find anything, here's a quick article on their token system - http://www.metakinetic.com/blog/2013/09/sage-pays-token-system-and-advancements-in-payment-gateways/