I have successfully used the PayPal REST API's to create and execute a payment in the sandbox, but even though I have shipping options and tax rates configured, they do not show up for the user. I expected the shipping options and calculated tax to appear before the user "approves" the payment. Is this feature supported via the REST API's, and if so what do I need to pass to make it happen?
The tax and shipping profiles are only for PayPal Standard transactions (the "Buy Now" buttons). API integrations like the Classic API and REST API are for more advanced integrations and are designed where PayPal returns the shipping address selected to you and your system chooses the tax rate and shipping rates before the customer confirms payment.
The PayPal shipping calculator only applies to Website Payments Standard transactions.
Express Checkout transactions will not use the shipping calculator.
https://www.paypal-community.com/t5/Merchant-services-Archive/Using-PayPal-s-shipping-calculator-with-Express-Checkout/td-p/328404
This is related but doesn't answer the question fully I'm afraid.
I've just started looking into applying different state taxes using the PayPal REST API. The override_charge_models option when creating a new BillingAgreement looks hopeful. It allows you to apply a custom tax amount when creating an agreement.
Related
I would like to make an API call to Big Commerce backend to complete a purchase on a customer's behalf. Based on the API reference:
https://developer.bigcommerce.com/api/stores/v2/orders#create-an-order
By default, I believe that one can only create an order that not yet paid by the customer. Please correct me if I am wrong.
So, my question is - How do you make a payment on behalf of a customer for the order? It is safe to assume that we have a tokenized credit card of our known customer in a payment gateway like Stripe.
My guess of how it could be done is when an order is created, I can set up a webhook to call the payment gateway to make a charge on the customer's credit card. Is this correct? Are there anything that I should watch out for?
Currently, you cannot use the BigCommerce API to process a payment or full transaction. We only allow payments through the control panel where you can enter credit card details or on the storefront made by the customer. If you'd like to make use of tokenization or recurring payments, it is better to use Rebillia or Recharge (apps).
As you stated, you would need to make a call to Stripe's API to charge the card on file with the customer's token. This should be fine. It won't make any calls back to BigCommerce, so I'd be mindful of error handling (such as if the card has expired) and how you'd retry or mark the order in BigCommerce. Depending on how it was configured, you would want to check order details to ensure you were only processing payments from API created orders.
I'm not sure of what PCI implications might be for the storage of the Stripe tokens. That would be another point for consideration.
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 just bought a script with the Masspay API needed to make an authorized payment at a specific time the "deal" ends.
With that said I am unclear why mass pay would need to be enabled for this feature.
If someone could please explain what Masspay is? And I have been reading that masspay is no longer availabe and I would have to contact paypal directly? Is this true for the sandbox accounts also?
If anyone has any information on this subject I am more than thankful.
Thanks.
If I understand your correctly,
Mass Payment is used for sending money.
If you are the merchant with record (you ship items and charge customers), then PayPal Express Checkout is what you want. You can DoAuthorization to hold the fund before you ship the item, and then DoCapture to collect payment after you shipped.
In you are part of the service provider, say you and another merchant both provide the service and own the payment from customer, then Adaptive Payment is what you need. You need call Pay after you shipped.
In simple terms Masspay allows you to make multiple payments to multiple people in a single shot using xls or csv files.
No, paypal is not sun-setting Masspay. This feature is still available and will be supported by Paypal.
I've always been super confused when it comes to mapping between PayPal's APIs (both "Classic" and the new REST APIs) and the actual PayPal business products (the account level ones seem to be Standard, Advanced, and Pro; there's also Payflow Link and Payflow Pro which acts as a gateway; and then Express Checkout which seems to straddle everything).
Specifically, do the "accept and store credit card" bits of the REST API require an Payments Advanced or Payments Pro account (the ones that require a monthly fee), or is any standard business PayPal account eligible to use them?
For anyone else running across this, it looks like a Payments Pro account is required.
Accepting credit card payments via Rest API's would need a pro account. Please let me know your contact information, if you're interested to have a pro account. One of our sales executives would reach out to you.
So I'm working on this website where users post their items, other users add some items to their cart and purchase them online.
The flow i was thinking about goes like this:
A merchant posts an item along with their credit cart/ paypal information.
A buyer adds items (from different merchants) to his/her shopping cart and purchases.
The buyer pays by filling a form that includes the payment method fields within the website's layout (no redirection to paypal).
The website will work as a gateway, it will capture the payments from the buyers and pays the merchants accordingly and automatically.
Is this possible using PayPal? if so, what API should I use?
Any input/idea is appreciated...
Thanks,
/t
I have also investigated using PayPal in this way for a site with a similar concept. Unfortunately, PayPal does not allow this. This makes you something known as a Third Party Payment Aggregator which drastically increases the risk associated with providing you a Merchant Account (which is what PayPal is doing). You can read more here.
Though, you could probably do it for a while before PayPal caught on, they could cancel at anytime leaving you high and dry. I recommend investigating Third Party Payment Aggregator solutions (Braintree has something that helps with this).
I guess it is. Use Paypal API
https://cms.paypal.com/us/cgi-bin/?cmd=_render-content&content_ID=developer/howto_api_reference
https://developer.paypal.com/