I'm integrating a react native app with PayPal's REST API and all has gone quite smoothly. However, when I click through, the buyer does not get the option to complete the purchase as a guest. I'm using a v1/payments integration; The transaction works if I login or create an account, but is it possible to let buyers pay without having to login?
I have researched and done most things people say you should do, like having a business account, enable guest payments, etc.
I tried using this github as an approach to using REST API, it works fine but if it helps: https://github.com/tonynguyenit18/paypal-RN-intergration
This isn't a REST API issue. You are getting the expected behavior of the PayPal Checkout in general. Guest checkout is available on a case-by-case basis. Very many factors -- such as the country of the buyer, IP address, repeated payment attempts, and testing payments to one's own account in the live environment -- are used to determine guest eligibility.
When a checkout is not guest-eligible, the buyer can still enter their card details but will also need to choose a password to create an account in the process.
Again, this is just how the PayPal Checkout works in general.
By the way, the v1/payments API is deprecated. You should use 'Create Order' and 'Capture Order', documented here.
Related
So I am building an app with react-native (expo) where a user fixes appointment with some other person and to do so, he has pay the other person.
Now how can I handle payments here. What i want is the user makes the payment and the receiver should be the other person but how much i understood the payment gateways, the payment is received by the app owner or in simple words, receiver is a single person.
I also tried deep linking to directly take the user to some UPI app like google pay or paytm but it seems that those apps require some special type of account (merchant account) to make the transaction if we access them using deep links (which is a problem as it is not necessary that every user will have a merchant account).
As I said, it is always better that you have your own payment gateway account, and all the transaction goes through your gateway, meaning you get the money and you build a system which will forward the payment to the receiver. I have worked on 2 such apps:
1: Where we have our own razorpay account, and we get the payment first, and then we forward it.
2: Where in we were directly having transaction between 2 users, but not through app, instead we display them the account details of the receiver and give them 48hrs time to pay that account. But we had to manually handle this scenario since one cannot know if the user has paid to the said account, since it's not your account.
3: There is one more method where in payment gateway has a webhook which consists of a virtual account number, and every user that lands on your app, you can create a virtual account number for him/her and store the user-virtual account number relationship in your db, whenever there is a payment, you can find out about the user through this virtual account number. Read about this.
The deep link is a good idea, but again, as you mentioned, it will require the end user to be a merchant user(have a merchant account), you can find more details here
Maybe you can ask your users to create a merchant account, which again I am not sure if it's possible, and if it's possible, if it's feasible?
The best way according to me is, you handle this through your payment gateway, and instantly forward it to the user who should have received it. Again there are some rules and clause to it(some commission is taken by those payment gateway,etc), check those things out.
I think the most close answer to my question is to use razorpay routes where we can link multiple accounts with our account and transfer money accordingly.
More details here
I have a requirement to do 3rd party age verification before I ship an order. I'm using a company called EVS for this. They released a shopify app recently, but seems partly baked. It requires a user to enter date of birth when registering for an account and then triggers the verification when the user places an order. The main problem with that is that it's rare for a customer to actually create an account before ordering for the first time -- instead they order first, then shopify emails them to create an account after the fact. Creating the account afterward does not allow the customer to enter DOB.
So I'm planning to implement my own solution. I can use EVS's API to run the verification by sending a combination of Name, Address, DOB, DL# and State, and last 4 of SSN. I have already built a proprietary order management system that pulls in customer and order data, and I can write a client to perform the verification.
I'm less savvy on the shopify side. I need to balance customer friction when placing an order for the first time, against having to do a lot of manual work for verification.
Below are the options I have conceived. Are there any other options? Any ideas for a better solution? Keep in mind I need to verify a customer once. I can tag the customer account as verified, and once verified it's business as usual.
Alter shopify templates to only show the checkout button when a user is logged in. If not logged in, show a "Create an account" button instead. That way the user provides DOB during account creation and the EVS app works as designed.
Set up a separate verification site like verify.my-domain.com. I can trigger an email to the customer upon order creation and ask them to verify. (May have issues with incorrect email addresses or spam filtering.)
If customer is not logged in, or account is not age verified, and they click Checkout, I can redirect them to a page. I can use a form on the page to do the verification. If verification passes, send them on to checkout.
For option 3, I don't know what shopify allows or what best practices allow. Can I use js to pass data to my own server on a different subdomain? Or post the form to another subdomain and then redirect back to shopify?
I'd appreciate any thoughts or suggestions.
You have pretty much summed up all your options, to clarify on them a little:
You can require that customers create an account in the store checkout settings. /admin/settings/checkout
This would work, you could iframe it in too on a custom Page. Or, better, use cross-domain calls or jsonp.
This is a little convoluted and you would have to persist and maintain lot of external state. I'd avoid this
I think a combination of 1 and 2. Turn on "require customer account". Modify the customer account creation page. Implement a cross domain policy with your server which will host custom code leveraging the EVS API.
I'm not sure if you are selling tangible goods or not but with stringent policies on users' age you have to bear in mind that shipping addresses could change. For a tight integration you should look at having webhooks whenever a customer is changed and make sure all their data is still valid since their last EVS approval.
I've been looking into this quite extensively and we've spent a number of hours experimenting with options. Our client in this case is on Shopify Plus so we do have the benefit of access to checkout.liquid.
Our research has led us to believe that one cannot pass the required 'customer note' of the date of birth to the checkout should they be attempting to checkout as a 'guest'. Perhaps because the 'customer' does not yet exist.
Our options have been narrowed down to:
Write a custom backend app that allows Shopify and EVS to communicate directly (XML API on the EVS side) in the checkout process or just prior and then pass the verification status back to Shopify to allow the order to proceed, or append some relevant status marker for the fulfillment department to act accordingly. The EVS app doesn't prevent the order from proceeding, but does flag the customer's age as unverified in the Risk Level panel in the admin. This would be quite a substantial project and by no means low hanging fruit. There is also risk of re-doing a lot of what the EVS app does already and running into they same obstacles they did.
Force customers to register prior to checkout (if not signed in). This seems the most viable approach. The only caveat being that existing customers will not have the customer note (birth date) and we'd need to build a smaller backend app to allow them to append this to their customer account via the Shopify API (this cannot be done via liquid).
These are our findings and I'd love to know more about how you ended up approaching this.
How is possible? Buyers Can Checkout Without a PayPal Account. Customers enter their name and shipping address.
They’re prompted for their credit card, email address, and phone number.
This is called "Guest Checkout". If you want to force that option you will need to use the Express Checkout APIs. Then you can add some specific parameters to ensure the guest checkout option is always prominently displayed.
Guest Checkout works with Standard Payments buttons too, but it is cookie based with Standard. As such, if anybody at any time has logged in to a PayPal account on the browser currently in use, the system will assume they are going to log again and sort of buries the guest checkout option.
Again, Express Checkout won't do that, and it's the #1 reason I get contacted by people about upgrading to Express Checkout.
I'm considering setting up a eCommerce website and was wondering about the payment side of things.
After some searching I came across Stripe, which seems very similar to PayPal and Google Checkout.
I have a few questions about Stripe and eCommerce in general.
What do I need to take payments on my website? Presume that I have the shop set up, and the buy button in place. Do I need an SSL certificate, I've read something about being PCI complaint? What is and why would I need a merchant account.
Stripe appears to handle a number of things for me, and it stores the users card details. How would this work with things such as logging in to a website. Would I store the users email and password and then when they wanted to buy something Stripe would just handle the credit card side of things or would the entire user details be stored on Stripe.
Can you build and style your own payment form that then connects to Stripe or do you have to use their form on your page?
Do you have to upload all of your products to Stripe or can you store these in your own database and just pass the value of goods purchased to Stripe for payment?
What are the advantages/disadvantages of Stripe and is there any competitors that I should know about?
Thanks
Stripe requests that you should serve up payments pages over SSL. Anyone involved in payment processing must comply with PCI, if you use something like Stripe you will need to serve the payments page on SSL, but Strip will handle the payment info. Check out https://support.stripe.com/questions/do-i-need-to-be-pci-compliant-what-do-i-have-to-do for more details on what you'd need to do.
Not entirely sure on this front, perhaps someone else can comment?
You'll be able to style your page and use Stripe for the payment piece.
You can use Stripe's checkout or build your own (sounds like this is what you want to do) via Stripe.js.
Stripe is generally recognized as one of the most developer-friendly ways to accept payments online. They've worked hard to build a simple service that a developer can get up and running a matter of hours. Braintree is a competitor that may offer some valued added services and you might want to take a look at Balanced as well. I work at LevelUp, which has been used in conjunction with Stripe (as another payment method, similar to PayPal) and as a stand alone solution for apps processing online or mobile payments.
I am so confused about the services and over here the paypal website also seems to be serving up 400's and 404s.
This is how the webpage looks for customers on my site when they are ready to pay:
As far as I know, I don't have Express Checkout, but I'm not sure if I have Website Payments Pro (my company created this account).
Now I have two questions:
1- This is just the sandbox. But on the real site, does this solution that give users the opportunity to pay by credit card? I've actually successfully done a credit card transaction in the sandbox, I'm just worried because I've heard that customers can only do direct credit card transactions in PayPal Website Payments Pro. The PayPal website is overloaded with information and I can't find my way around it to answer simple questions like this.
2- Is it possible to do negative testing for transactions on this page? Such as simulating the events that the user's credit card or Paypal account doesn't have enough balance? If it is possible, and I am using the ButtonManagerAPI, then is the technique below the correct way to go about it?
I put an error code in the amount variable that is passed on to IPN via via an NVP api call, like this (lots of value pairs in the middle excluded as irrelevant):
$nvpReq = "BUTTONCODE=HOSTED&..............&L_BUTTONVAR1=amount=".$err_code
EDIT
So it appears I have PayPal Website Payments Standard, which means I cannot incorporate cannot have credit card payment forms directly on my website, but customers have to be directed to PayPal. I'm fine with that, as long as customers have the option to pay with credit cards.
The screenshot looks like PayPal Standard, which is an HTML-only (non-API) integration.
Any regular business account that can receive money can make use of the Express Checkout API.. typically by authenticating with an API USER/PWD/SIGNATURE. For businesses with programming/development resources, EC is by far the recommended way to accept PayPal payments.
If you pass SOLUTIONTYPE=Sole in the initial SetExpressCheckout call, it will accept credit cards from "guest" customers who don't have a PayPal account, similar to the Standard screenshot you're displaying above.
The main reason to choose EC over Standard is that it's a much tighter handshake between your checkout software and PayPal's servers. With Standard's HTML-only, the customer is redirected away from your site and might not return to your site after a successful transaction is committed (they may stay on paypal.com and not click to return or their browser might crash before return --- whereas with EC the return to your site is built-in before anything touches the financial system)
With the recent beta of developer.paypal.com, all new sandbox Business accounts are full Pro accounts by default. Signing up for a live Pro account would be useful if, in addition to accepting PayPal payments, you wished to create a credit card entry form directly on your own site.
Here are some EC links for programmers:
https://tryit.paypal.com/guide/ec
https://paypal-labs.com/integrationwizard/ecpaypal/main.php
The button manager API is unlikely to be useful to you. And there are ways to do negative testing with the sandbox, but it's really not an important concern when you're still deciding on a product/API.