We offer an additional checkout option for our merchant partners (similar to PayPal).
Customers can checkout by selecting our checkout button on the checkout page; these customers must have already registered with us and added a credit card to their account.
We offer two options for Merchants to integrate with us:
API (web services) or
Form (POST).
When a customer checks out by selecting our button, the following steps occur:
customer is presented with a login dialog to be authenticated
if successful and order is approved (by our back-end system), the customer is notified of this on the dialog box (web service) or form (hosted; then sent back to the merchants site).
the order in the merchants site is updated with the success status and with the customers billing/shipping information from our system.
Does Shopify have APIs that will allow us to do the steps above?
There's no direct API to do this.
Shopify uses (a version of) ActiveMerchant for all payment processing services, both on-site (e.g. Stripe) and off-site (e.g. Paypal). If your service is integrated into ActiveMerchant, it can be integrated into Shopify.
HOWEVER:
Just being integrated into ActiveMerchant doesn't guarantee Shopify inclusion. We already integrate with many payment services, so any new offering must also be attractive on a business level as well as sound on a technical one before we'd consider adding it.
Related
I am currently looking into the W3C Payment Request API as part of a project for a new e-commerce checkout flow (mostly for supporting faster check-out using Apple Pay and Google Pay).
From looking at the API specification's change history, it looks like this change instituted earlier this year removes support for requesting the buyer's address with a payment request. The documentation of our payment service provider still shows this option, and it seems to work for now. That being said, I don't want to rely on a feature that browsers might start dropping soon because it's no longer in the standard, breaking our checkout flow.
Does anyone know if there is a recommended new way to handle this via the API, or if it is advisable to move the collection of the buyer's billing and shipping addresses back to a form on our page even when using the payment request API?
As far as the Payment Request API is concerned, I think there three primary options:
Apple Pay
Google Pay
basic-card
As you may have seen, basic-card is being deprecated (https://blog.chromium.org/2021/10/sunsetting-basic-card-payment-method-in.html) so you probably want to avoid this option.
Both Apple Pay and Google Pay provide access to billing and shipping address, and can be accessed as payment methods in the Payment Request API, and both provide their own alternate APIs (Apple Pay JS API and Google Pay Online API).
I don't know about Apple Pay, but the advice for Google Pay is to use Google Pay Online API (which makes use of the Payment Request API when available). Google Pay provides a consistent API for browsers that do and don't support the Payment Request API.
Does anyone know if there is a recommended new way to handle this via the API, or if it is advisable to move the collection of the buyer's billing and shipping addresses back to a form on our page even when using the payment request API?
The guidance for Google Pay is to place the Google Pay button above manual entry fields and to collect shipping information from Google Pay so that users can users don't start filling in the form before realizing there was a faster checkout option available.
So prioritize the digital checkout options for users that choose to use it, and make use of billing/shipping information from the digital wallet APIs. Make manual form fields available (suggest that form fields also make correct use of autofill attributes) for users who don't have access to or choose not to use the other payment options.
Demo site available with this in action: https://paydemo.withgoogle.com
FYI, if you're looking to integrate Google Pay into your site and are using a JavaScript framework, consider using the framework specific components from Google Pay for easier integration: https://github.com/google-pay/google-pay-button
Shopify is suitable for selling online services, tools or not? Is it possible to use Shopify in the same way as PayPal or any other payment processor, for example simple purchase flow:
1) user clicks the 'Buy' button,
2) page navigates to the Shopify product page where user has to pay (commit the purchase)
3) redirects back to the website with purchase confirmation and token - which is used to link it to the buyer (user that clicked the Buy button).
this should be common and pretty simple, though I couldn't find any tutorial or sample
Yes, it's possible.
Create a store, set up a payment processor, create a product that is (a service, a tool or whatever you want to sell) and you're ready to go.
Also, read bout selling services.
Yes, it is possible but shopify is mainly used for selling physical products.
You can use 'Digital download' apps on the Shopify AppStore. After the customer purchases your digital goods, it will show the download link to the customer. The official free shopify app is ok enough
If you're selling subscription, you can use subscription apps.
Personally, I prefer to use gumroad since it's solely used for selling digital services
How shall I integrate custom shopping cart app with PayPal to accept indirect credit card payments without forcing buyers to register at PayPal?
There's a custom shopping cart web application and the task has been set to replace current credit/dept card payment with PayPal. The goal is to let the customers pay with their cards via PayPal. However, there are some constrains:
customers should enter their credit cards details (number, expiry date, secure code) not in shopping cart's page, but PayPal's page,
every payment must consists of authorization (blocking total sum) and subsequent capture if the ordered items are available and can be delivered,
customers aren't forced to create / login to PayPal account if they wish to pay via card.
The trouble is I'm really confused with the number of possible options at PayPal. The choice between REST API and Classic API isn't that problematic, but choosing the proper product from the whole list (like Classic API products or REST API products) isn't that obvious for PayPal newbie. Some other similar questions point to DoDirectPayment (but I don't know if it's the best choice) or suggest Website Payments Standard (I'm not sure if they're still available).
I was also considering Express Checkout, but the demo seems to force to create PayPal account.
ExpressCheckout is designed to be used in concert with a direct credit card acceptance method (such as PayPal's DoDirectPayment, or a non-PayPal credit card acceptance method), although it can be configured to also do guest payments. This is why the demos of the normal configuration handle only PayPal account creation; that's the normal usage.
One key question you need to ask yourself is whether you want to have access to the credit card information & be the "merchant of record" yourself or not.
YES: Doing this gives you the most flexibility, but will require you to go through some merchant vetting and carries some security obligations (PCI) even if you are using some solution which tries to distance you from the actual raw card numbers (e.g. collecting them via PayPal or Braintree code and immediatly encrypting & tokenizing them). In short: if you want full access to the card, then you have legal obligations re: handling that account access which technology can reduce but not eliminate.
NO: If you are content to always treat your customer's card information at arms length through PayPal, via the legal structure of a PayPal account (whether the user actually has a PayPal account or is just doing a "guest" payment on PayPal where they give PayPal their credit card for one-time use) then you can reduce your vetting & security constraints (no PCI requirements at all).
If you want (or need) access to the customer's card [YES above] then the "classic" API solutions are either DoDirectPayment (for when you collect the card info) or Hosted Sole Solution (for when PayPal collects the card info on their page). HSS meets all 3 of your requiremens above; DDP fails requirement #1.
If you can live with access to the customer & the payment but NOT the card account itself [NO above] then you can use Website Payments Standard, or EC with Guest Checkout option; both meet all three of your requirements.
All of the above solutions are not only still supported, but have tens or hundreds of thousands of integrated merchants and are the biggest/mainstream ways in which PayPal payments are handled.
If you prefer the newer products & are in the first category above (real card access, not guest payments) then you can also use Braintree or the RESTful APIs. These newer products don't yet have as much flexibility & coverage as the older products, but hey, less complexity can be a good thing as long as they have what you need. These products are generally designed around plugins for your web pages rather than entering card information on PayPal's site, however, so they don't meet your first requirement.
You can also do PayFlow (several variants) or Adaptive Payments or or or.... but in general I would advise picking either the most well-established or the new-and-growing options as being better supported & more future-proof.
Now that PayPal has acquired Braintree, the preferred integration method is v.zero. It is designed to be very easy to accept PayPal, Credit Cards and other options. (Venmo, Bitcoin, etc.)
I want my customers to be able to login to my Shopify store via my existing website account system.
This means that if they've already entered their address on my website, they don't need to enter it again in Shopify. (And if I can also track my users' shopping behaviour that would be a bonus.)
I found this related discussion on the Shopify forums (about Facebook login), but with no clear answer:
https://ecommerce.shopify.com/c/shopify-apis-and-technology/t/login-with-facebook-114126
Is it possible to use oAuth (or some other method) to enable this kind of functionality in Shopify?
The official Shopify method to login to your store from your third-party website is to use Multipass, however this requires a Shopify Plus account (starting at $995/month).
Shopify does provide some support for oAuth, however it appears to be mainly used for shop-owners adding third-party apps into their stores, not for creating customer accounts.
There are various apps available for social login functionality. While these won't exactly provide the functionality you need, they must have a found a way of creating new user accounts, so perhaps they can hint at a possible solution for this.
See https://apps.shopify.com/search/query?utf8=%E2%9C%93&q=log+in
I'm trying to create a shop that requires paid membership to use. I love what Shopify has to offer. Is it possible (with their API or by using an existing app) to force users to purchase a membership before they can access the store?
It is trivial to do if you can setup a subdomain and use Stripe. No one gets into Shopify without having an account, and no one gets an account except through you. Once they buy a membership via your Stripe form, you create their Shopify account, and send them their invite to use the Shop.
Nothing could be simpler...