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.
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
We want to start a service with Mailchimp where every subscriber will get a customized link in the email she receives. The Subscription Form will be on a wordpress website (not my decision).
There is a pool of thousand of links with a unique parameter, which we have stored on our webserver, like these examples
https://example.com/link?code=a25b1d085f3aec4b256
https://example.com/link?code=32219abb336de28a103
etc
Every code parameter should only be used once and should be kept as secret as possible. So I don't think it is a good idea to send the code from the form to mailchimp in a hidden field.
I don't know, if this is possible. Is Mailchimp even the right tool to do this?
I'm not sure, where to start the journey.
I don't think webhooks will help me here, as those are only one-way communication without a backwards channel, as far as I understand.
I checked the Mailchimp API documentation, but I might be too foolish to understand, which of the multiple options I need to use.
I found this answer here: https://stackoverflow.com/a/53096852/476951, but I don't know, if this will suit my needs. As I understand it, this will chhange the mail template in Mailchimp UI with an API request and store it. The successive emails will all use this changed template until I change the template again. This seems not to be the correct way.
So, here are the two workflows that might be possible, but I don't know if they are.
Have a form created in Wordpress (not the embedded Mailchimp form), and create a custom form handler with admin-post.php like described here. Then use the API to send the email through the Mailchimp service with my dynamic link in it. But how. Every tuorial I found sends campaigns via the API, not individual mails to single recepients
Somehow manage Mailchimp to get the dynamic content via some sort of webhooks or the likes.
Is any of these workflows suitable to do this?
If yes, who should I set these up?
Is there anything else I might have missed?
Edit
Or do I need to use Mailchimp Transactional Email service (former called Mandrill)?
I am creating an e-commerce API using the Django Rest Framework. The API will handle the following areas:
Databases
User Registration
Permissions
Orders/Payments
There's still one area in which I'm not quite sure how to implement in my project. It's the cart functionality. Would it be better to implement it on the client-side (ex: React/Ember) or on the server-side (i.e. API)?
One scenario that confused me is if the user is logged in in different platforms (ex: Website and mobile app). I want the user to have the same cart on mulitple platforms.
In that particular use case, if you want cart persistence then it must be backend. The reason for this is one being able to have a single source of truth. The phone app and the web app cannot talk to each other unless they have some sort of "common ground" between them.
That's where the API comes in. It will allow both ends to speak to each other by having the API as the single source of truth. See my terrible diagram for a visual.
I've been working on a secure shopping cart and checkout for a website. I'm using PayPal, and I'd read that PCI requirements aren't as much of an issue if we don't store card data on our site, so if possible I'd like to avoid that.
HTML buttons seemed like a promising option, but upon further investigation, it seems like maintaining control of active user sessions may not be possible. Below are my sources that seem to confirm this.
PayPal button return url usage
delete session variables when session id is known but not able to start session
PayPal payments pro is mentioned in the second post, but I'm wondering if it or anything else meets my 2 design constraints as they're implications for the implementation don't seem to gel very well.
If they are losing session data when returned from PayPal with a standard button then they have something else going wrong. That should not be happening.
That said, if you're comfortable working with APIs I always recommend Express Checkout and Payments Pro.
If you prefer REST APIs you can use that for PayPal payments and direct credit card payments.
If you prefer NVP / SOAP you can use the Classic API.
In any case, keeping session data alive won't be an issue, and as you mentioned, as long as you aren't storing any credit card data on your server in log files, in the database, or anywhere then you won't have to worry about PCI compliance.
I need to download all existing payment information from a paypal account to do some analysis on it, so I set up paypal's ruby rest sdk, which involved creating a new application with its own API keys and whatnot. I can make a successful request with the following:
payment_history = Payment.all( :count => 10 )
However,
payment_history.payments
Is empty.
I'm not sure if this application can only access payments created with it? Can I not get pre-existing payments with the rest api? I would prefer to use ruby, if that's possible, as I would like to keep this all within the simple script I have to analyze similar stripe payments.
Some guidance would be extremely appreciated, as paypal's labrinth of documentation and overlapping APIs have me pretty confused.
You will be able to query only those payments that are made or created with Rest API not the Classic APIs. You can use the Classic Ruby SDKs for the appropriate product to get the Transaction details of the classic APIs