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
Related
I just want to ask how to implement this process in my Laravel 7 app.
On a logged user, he will setup his payment method using Paypal account (some redirection to Paypal page)
After success registration/setup of Paypal account, the app can now charge customer with service/products he availed.
This is not a subscription or recurring payments.
I'm reading the Paypal API Docs but I don't know where should I focus since I don't know the real Paypal Terminology for that kind of process.
NOTE: I already implement this kind of process but on Stripe only where the customer setup his Card or Bank Account then the app can charge the customer.
On PayPal this used to be known as "Reference Transactions with Billing Agreements", and in very new integrations it's called Vault (v2 REST API vault, not the old v1 REST Vault which is of no use)
This functionality is only available if PayPal turns in on for your production account, so you need to contact PayPal about it, specifically the business side of PayPal via https://www.paypal.com/smarthelp/contact-us (not the MTS technical support, they don't enable new features)
If reference transactions does get enabled and approved for your live/production business account (no guarantee of this), then PayPal will guide you on which specific API to use, which could be the newest v2 Vault or something else.
Help me please. How to integrate Apple Pay in Xamarin.Forms? The instruction that is on the Microsoft website does not provide a step-by-step algorithm for implementing this functionality.
Maybe there is a plugin that helps solve this problem? I tried to register at www.judopay.com, as indicated in the Microsoft manual, but no one answered my application.
There is no direct detail tutorial in Xamrarn , however Xamrin provide a Emporium sample and original document from Apple to explain that .
The sample app is comprised of several parts:
CatalogCollectionViewController - a collection view that displays a list of products (parsed from ProductsList.plist)
ProductTableViewController - a detail table view that summarizes a product, and allows the user to buy it using Apple Pay
ConfirmationViewController - a simple confirmation screen to be shown after a successful payment
Hope this sample will be helpful to create your first apple pay application .
In addition , the most important logic is Processing the Payment Token:
Once the user has authenticated to confirm purchase intent, you don’t need to handle their actual credit or debit card numbers. Instead, your app or website receives a payment object containing an encrypted payment token. This token encapsulates the information needed to complete a payment transaction, including the device-specific account number, the amount, and a unique, one-time-use cryptogram. The token can be decrypted by the merchant with the certificate private key or by the Payment Service Provider (PSP) on behalf of the merchant. Once decrypted, the token needs to be passed to the payment service provider for processing.
More info , you can refer to Apple doc here .
I need to implement PayPal payment in my Laravel site. I was going for the server side integration, in order to save all the data, transactions and know what they actually bought. But turns out that [the older] server-side integration method [that I was looking at] is archived, and not really the preferred method anymore. Instead, they suggest using the smart buttons, with front end integration only.
Questions:
Is front end only safe? what prevents the user from messing with the JavaScript and editing the sum with whatever they want?
How do I know what they ordered if it is all front end?
What would I have to do if the payed sum does not correspond to the articles in the cart?
What should I be aware of with this system?
Smart Payment Buttons can be used with or without a server-side component.
Here is the front-end pattern that communicates with a server-side integration: https://developer.paypal.com/demo/checkout/#/pattern/server
Notice the fetches to two '/demo/...' placeholder endpoints, which need to be replaced with actual routes of yours. The first should create a v2/order via API and return the orderID. The second should capture that order after the payer approves it via Smart Payment Buttons.
The answers to your questions re: a serverless (client-side only) pattern are:
Nothing
Only what you program the JavaScript to tell you and which it actually successfully tells you, or what you read via email or in your PayPal account or app notifications
Refund the transaction
It's for people who don't want to do the work of implementing server-side routes and API calls.
I'm currently interested in using Braintree to make payments from a server using credit card credentials that I currently hold to another payment server.
Currently, the payment nonce is generated by the Braintree Client SDK when a client enter in his credit card details.
However, I want to set it up such that my server, which already contains my credit card details, will generate the payment nonce and send it to another server which accepts Braintree payment nonces.
Full disclosure: I work at Braintree. If you have any further questions, feel free to contact support.
If you already have the credit card details, you can first create a payment method from those. Once you have a payment method you can treat it just like you would a nonce to create transactions.
Just keep in mind this has additional PCI concerns with raw credit card data being present on your server.
With the old Braintree API it was possible to just store credit card details in the vault to charge later (for a variable subscription model). Is it possible to do this with their v.zero API? I looked at their documentation and it wasn't clear. It mentions it can do it with Paypal accounts but I'm not sure if this includes credit cards (no Paypal).
Full disclosure: I work at Braintree. If you have any further questions, feel free to contact support.
Yes! When a customer fills out their credit card information in the Drop-in it is processed by the Braintree API. Once complete, the client receives the payment method (i.e. credit card) nonce which should be sent to your server. This nonce can be used for a whole variety of tasks including simply storing in the vault, as you are trying to do:
result = Braintree::PaymentMethod.create(
:customer_id => "131866",
:payment_method_nonce => nonce_from_the_client
)
Steps:
Your client embeds the Drop-in
User fills out data in Drop-in
Client receives Nonce
Client sends Nonce to server
Server uses nonce to create a payment method in the vault
Cheers!