To me it looks that using PayPal Smart Buttons (Javascript SDK) can be unsafe.
In the SDK url you have to send your PayPal client-id (
).
This means that every visitor of your site can see your PayPal client-id, so they might abuse that (if they want).
Am I right?
The client id is a public credential, for client-side operations. The secret is not.
Related
I'm trying to integrate a payment gateway like razorpay or stripe in my flutter app, and for any payment provider we need to generate a token using their API in the backend , but none of these payment providers have mentioned the code for the server side to generate tokens and how/where to deploy that server side code. Essentially I'm creating an ecommerce app and to process payments I can't find resources to implement the server side code for each cart order. Can anyone tell how to implement the server side code or some resource which could be useful?
Docs I have read:
https://pub.dev/packages/razorpay_flutter
https://razorpay.com/docs/payments/payment-gateway/flutter-integration/standard/build-integration#16-create-an-order-in-server
but none of these payment providers have mentioned the code for the server side to generate tokens and how/where to deploy that server side code
This is by design. Payment providers help you lower your PCI compliance burden by not touching raw card details. If you use frontend SDKs (like Stripe's Stripe.js + Elements UI library), they are an iframe that collects your end customer card details directly to their servers meaning your integration does not touch card details and does not have to do tons of paperwork on your own PCI compliance.
https://stripe.com/docs/security/guide
https://stripe.com/guides/pci-compliance
So you absolutely need to use their frontend SDKs to directly create a token from your webpage.
I can't find resources to implement the server side code for each cart order.
Once you have your token, you then send that to your server to create an order and (in Stripe's case) create and confirm a PaymentIntent. Though Stripe's recommended flow is a bit different - you create the PaymentIntent first and "confirm" it on your frontend: https://stripe.com/docs/payments/accept-a-payment
For razorpay integration (atleast as a payment gateway) you will be in need of a client and a server. As you say you have the client with you. After the user initiates the payment and completes it in the flutter client - the client has to send out an api request to the api server that can actually capture the payment with the hash comparisons.
I don't not much idea about Razorpay integration but for Stripe you can use Payment Intent API.
You can divide the process in 3 steps:
Send card details from Front-end, if it's a Stripe Customer then you can even use their default card.
Create a payment Intent in Backend, this will return a payment intent object with client_secret. You also might wanna save the payment intent id in DB.
Send this client_secret to Frontend, where you can use this client secret in Stripe.confirmCardPayment(client_secret).
Listen to webhook events to check on the payment status/progress. It's basically an open endpoint where stripe will make REST calls and provide you with details about your payment progress.
Here's a link to the docs mentioning this process. There was an even better doc/github link that I can't seem to find, it had the entire end-to-end happy process.
If this seems a bit complicated then you go with checkout API of Stripe. I've also attached a few youtube videos that might help ya in getting started.
Checkout API YT link
Payment Intent YT link
I’m developing a delivery application that will work with PayPal for payments. Ionic/Cordova has a native library that makes things easy, yet the flow is not the way i’d like it to be.
With “PayPal-Cordova-Plugin”, the authentication window opens for every payment and the user must click the button to confirm the payment.
What I would like to implement was something more direct, transparent. The user would authenticate with PayPal within my application and with the probable token that would receive this authentication, I would execute the checkout requests (an example would be the payment by PayPal on Uber).
With the PayPal developer documentation I could not find a way to perform this implementation on Ionic, so I would like help with that.
The old PayPal Mobile SDKs used by the cordova plugin are ancient. Do not use those. Do not use those for anything. If you try to use those, you are going to have a bad time.
The first paragraph at the top of the Readme of https://github.com/paypal/PayPal-Cordova-Plugin points you to the things you should be using instead.
As is mentioned there, PayPal Express Checkout via the Braintree Mobile SDK is a worldwide option for those who need a native SDK. It is documented here: https://developer.paypal.com/docs/accept-payments/express-checkout/ec-braintree-sdk/get-started/
You will need a webservice for the server-side portion.
I'm trying to implement the PayPal checkout server flow described here and I'm a little bit confused about the role of the redirect urls required by the Create Payment REST API
With the PayPal checkout JavaScript components, I need to provide a onAuthorize hook in the JavaScript button initialization code like in the example on the page linked above. My understanding - and I've confirmed this in the sandbox environment - is that this callback gets called after user has successfully authorized the payment on PayPal and in this callback I'm supposed to execute the payment. This part is pretty clear and I've successfully implemented this. The confusion arises from the payload on the PayPal's Create Payment API.
This API expects a required parameter redirect_urls to be provided in the payload. Under this both return_url and cancel_url have to be provided. I understand from the documentation these URLs are where the user will be redirected after successfully authorizing the payment or if they cancel the payment.
In my tests in the sandbox environment, however, the user is never redirected to these redirect urls, as the "return" / "cancel" is handled by the callbacks provided to the button initialization. Now this leads to my question:
Despite this, is there any scenario where the user is redirected to these urls? What should happen if the user is redirected to these urls?
My concern is do I need to duplicate the on authorized / cancelled logic both in the JavaScript code and then upon entering the provided return urls?
The return and cancel url were important in cases where the PayPal experience is not in context (light box ) or if you want to take them to a completely different page once they approve the payment using continue or pay now or if you are using this in a mobile app where the checkout.js won’t work
With the checkout JS integration you don’t really need to pass the url as the experience is in context if that’s what you were trying to ask.
I've been asking myself if there is a possibility to use the standard payment page of paypal to redirect user to "Authorize" a payment using their Credit card (using "paymentaction" : "authorization" in the redirect form).
Having IPN setup i could receive the auth_id.
Then later on "Capture" an amount (equals or less) using the Paypal REST API but using the "auth_id" received through IPN ?
It seems the "authorization_id" received through Paypal REST API "Authorize" is the same length. Somehow i suppose it is the same value.
Before implementing such i wonder if anyone tried this before ?
Thank you
You can do this using the standard (Website Payments Standard) page to creat the authorization paired with the "classic" authorization API, but you cannot mix the classic and REST APIs as you described.
The REST APIs store different/additional information on PayPal's server side, so in general you cannot manipulate transactions created through classic APIs via REST APIs (and vice versa is also complicated and generally not advised).
I'm implementing chained payments using PayPal Adaptive Payments API. We have iOS and Android applications.
Authorization form on sandbox.paypal.com/cgi-bin/webscr?cmd=_ap-payment&paykey= looks ugly on smartphones (both iOS and Android):
http://cl.ly/Vhvu
User-agent is correct (I've tested it in Safari development).
Is it possible to provide parameter to show mobile layout of this form?
Anyway, I also tried to exchange this url with embedded payment experience:
sandbox.paypal.com/webapps/adaptivepayment/flow/pay?paykey=
but it doesn't work with any expType options always showing the error:
Please try again later. Payment can't be completed. This feature is currently unavailable.
apkey is definitely valid, becuase the same key shows authorization form if opening with "webscr?cmd=_ap-payment" url.
So, is it possible to get pretty look of Adaptive payment authorization form on iOS and Android and what method is better, classic (webscr-url) or embedded?
It seems that the problem is caused by senderEmail. If you remove it from the request, it would work. Please read more here:
Embedded payments and 'This function is temporarily unavailable' error
(PayPal should be ashamed of its user interface. Can't they afford a UI designer to design a responsive UI for their ONE PAGE payment? Embedded UI is full of bugs >.<)