I'm using the PayPal API from PHP/Laravel and the purchase total is bugged. It results in a payment with the correct amount from the credit card, but when showing the amount to the customer during checkout, it only shows a 0 total
checkout screenshot
Do not include a start_time (date) when creating the subscription.
https://prnt.sc/pOK5-7v5ZYMY
You should always uput text in code blocks, either with indentation or surrounded by three backticks, ``` before and after the code. Never take a screenshot of code.
It would appear you are using the old PayPal-PHP-SDK, which is deprecated. Do not use it for anything. (separately, that SDK also uses an older version of PayPal Subscriptions with billing agreements; current Subscriptions API does not use agreements).
The current version of PayPal Subscriptions integrations is documented here. There is no REST SDK for it. For any API calls, you can use direct HTTPS REST calls, first obtaining an access_token using the client id and secret. (If you need sample code for that, the current Checkout-PHP-SDK's classes or functions might be useful as a base, but it does not include support for Subscriptions API calls, which you need to write yourself)
Related
This is my first time using the PayPal API so go easy on me.
The case I am trying to handle is as follows:
My customers can purchase software licenses that can either be one time payments, or yearly payments.
They can multiple products to the cart, and each product can have either one of the pricing plans mentioned above.
If I understand correctly, "payments" in the API handle one time transactions, and "billing plans" are used for recurring payments.
Is it possible to processes both in one call to the API? If not, is there a different way to achieve this?
Any suggestions would be greatly appreciated! TIA!
Not one API call, but you can do it in one checkout flow with multiple API calls.
For PayPal wallet payments (logging in to PayPal and paying) I would recommend using Express Checkout w/ Recurring Payments.
With that you would be using SetExpressCheckout, GetExpressCheckoutDetails, and then either DoExpressCheckoutPayment, CreateRecurringPaymentsProfile, or a combination of both of those depending on the products in the card and whether they need one-time payment or recurring.
The CRPP call will allow you to setup a recurring profile and include an "initial payment" which would be charged when the profile is created. This could be used as the one time payment if you want, and then you wouldn't need the DECP call.
Alternatively, you could use DECP to process the one time payment and then follow that up with CRPP to create the profile. There are advantages and disadvantages to the different methods depending on your business needs.
For setting up profiles with direct credit cards you'll need PayPal Payments Pro. In this case you would either use the same CRPP call mentioned above, but it would be used by itself and include the credit card details. Or, depending on the version of Pro they put you on, which depends on the version of PayPal account you have, you might end up using PayFlow instead.
If you're working with PHP this PayPal PHP SDK will make all of those API calls very quick and easy for you.
I know that's a pretty broad answer, but that's because it's a pretty broad question. :)
I am working with paypal first time.
I have a product and I want to integrate paypal with it.
I want to achieve the following tasks :
Client comes to my website and select a plan,which is a monthly recurring plan.
Then client is redirected to Paypal for payment.
Client makes payment.
Return backs to home page.
I have gone through the documentation of paypal and I have the following questions.
What should I use REST API or Classic Sdk, as I want to create Recurring Profile,Work with EXPRESS-CHECKOUT and REFERENCE TRANSACTIONS.
I have customers all over globe and it is stated in the documentation that, for the customers in Germany and China , I have to use REFERENCE TRANSACTION.
Some where in the documentation of Merchant SDK it is stated that the classic API's will be deprecated, so is it a good approach to use Classic SDK
I also wanted to track the transactions(payment) made by user, so that I can show him the amount that is deducted in each month in his profile details.
Please suggest a feasible solution to my problem.
Thanks in advance.
Here's what I use. I went to Web Payments Standard and created a Subscription button. (I like the unencrypted variety, but you can encrypt if you want.) In there, you set the terms of the subscription, as well as where to post the IPN message. When the IPN message comes back, you deal with it. You'll get a subscr_signup at the start along with a subscr_payment. Then, on renewals, you'll get a subscr_payment again. What I like to do is store every verified IPN message in the database for my customer.
For handling the management of those subscriptions for things like tracking info, refunds, subscription cancellations, and voids, you'll need to use NVP API, which is a very simple API. If you stored in a database every IPN message with all those fields, then you should be able to pass certain fields of those to the NVP API in order to get what you need done.
If you're worried about longevity of the APIs, then don't. All they do when they deprecate APIs is stop giving you good docs on them. They still let those older versions run. If they didn't, there would be major upheaval on the web with web commerce products breaking all over the place. However, that said, if you want to prepare for the future, then get on the Braintree Payments API because PayPal bought Braintree and that's the future of their API.
I am testing the PayPal REST API for subscriptions in the sandbox environment, and have noticed that, when going to the approval URL returned after creating an agreement, no price is shown under the order summary pane on the left of the page. A description is shown but no price/tax etc.
The plan id is passed to the call to create an agreement, which contains the information that I would expect to see as a user when approving the payment. Is this a bug or is there something that I am supposed to enable in the merchant account, or perhaps something additional that needs to be sent when creating the agreement? I've read other posts regarding this on stack overflow (although they predate the creation of the subscriptions REST API) talking about passing a transaction field, but this isn't valid in the subscriptions create agreement schema.
Your observations are (currently) correct. As REST API based Billing Plans are based on Express Checkout Recurring Payments, you're going to see a similar behavior.
Right now, there are two options:
You populate the description with more agreement details.
You pass a regular description and make sure the customer is aware of the billing terms before your execute the agreement.
Going forward, we're likely going to include this info in some later updates. I'm following up with that to make sure a user story is filed for this.
I'm trying to use PayPal REST APIs instead of Classic APIs for forward compatibility. What I want to do is to save user details and make a payment later. The point of making a payment could be several months later. It seems it's possible with the Class APIs, though it looks not perfect.
However, I cannot find how to do that with REST APIs. It seems not possible, but I want to check if I missed something.
These what I found.
I can make an order and capture it later, but an order is valid only for 29 days.
I can make a recurring charge with billing plans, but the point of making a payment is undefined in my case.
I can save user's credit card detail in the Vault and use it later, but I don't want to make users put their credit card details.
So, in this case should I use the Class APIs?
I'm interested to see if anybody is looking to integrate Woocommerce with the PayPal Here payment App? More so the importing of products from Woocommerce to the PayPal Here App. Be a great addition.
I haven't looked into that specifically, but I will be adding a "virtual terminal" / POS functionality into my PayPal for WooCommerce plugin before long. I've got it planned for the next full version release.
It basically gives you a section in the WP admin panel where site owners can easily put together invoices using their WooCommerce inventory and then process those orders accordingly. I will be including the Invoicing API's so you can create an invoice from the Woo VT order page, or you'll also have the ability to swipe a card using a USBSwiper card reader. Of course, you could also key in card data if you needed to do it that way.
The cool thing about that is even when you key in the transactions you still get your 2.2% - 2.9% rate depending on your volume because it would be processed over Payments Pro in that case. Same with invoicing or swiping.
Back to your original question, though, I'm unaware of any API or tool that allows us to interact directly with the Here inventory. They do have the Sideloader API for PayPal Here, which would allow you to send inventory (or a specific order) into the Here app from your own app in order to complete an order, but I don't think it lets you push inventory directly into the actual Here app.
On that note, what I could potentially do is build a stand-alone app that does nothing but pull in current WooCommerce inventory, and then from there you could create orders through the Sideloader API using that inventory, but it would use the Here app to actually complete the order. Seems a little clunky, but in theory, that should work fine.
If you want to contact me directly we could discuss getting this done for you.
Right at this time PayPal Here is designed to be card present, so you cannot import your products from Woocomerce into the PayPal Here App.
Here is a link to an FAQ on PayPal Here:
PayPal Here FAQ
Here is the current list of PayPal Here Partners:
PayPal Here Partners