My company is providing service, which has few subscription plans with different monthly fee. Everything is working via PayPal recurring payments.
I want to implement upgrade system, so clients could switch to more expensive plan.
For now I found two solutions:
Modify current subscription and ask for payment to cover difference in plans to the end of the month (modified subscription will work only from the next month). So basically I need to give my client two different forms to submit to PayPal, which is very bad.
Also I could cancel current recurring payment and ask client to subscribe for new. Cancel is possible in the background without any user interaction, he only need to submit new form for new payment.
I like second method more, but it still not very clear for users and I'm looking for better solution.
Sounds like option 2 would be the only viable one.
For upgrading have your script put them on a new subscription, then on your script that processes the PayPal reply, have it check to see if the user already has a subscription, if they do, then create a paypal request to cancel the old subscription.
Although this is a very old question, I found it while trying to implement this kind of upgrade and I believe might be interesting for other people.
Now, you can upgrade paypal subscription amount programatically. More info here:
https://developer.paypal.com/docs/classic/express-checkout/ht_ec-recurringPaymentProfile-curl-etc/
https://developer.paypal.com/docs/classic/api/merchant/UpdateRecurringPaymentsProfile_API_Operation_NVP/
However, this has the limitation that you cannot upgrade more than 20% of the current amount for half a year. In my case, and probably many others, the best option is to cancel the current subscription once the new subscription has been approved.
If you need to start charging the subscription next month, it can be easily achieved with the starting date parameters or giving a free trial.
Related
I am using Stripe to test how my code would react to recurring subscription renewal payment attempts for a product we are working on (need to test success, failure ...etc.). And it seems that most answers on StackOverflow suggest creating a subscription with a recurring payment of 1 day (which is the minimum recurring payment available at Stripe), and waiting until next day to see how my code would react to the webhook notifications. (By the way, I could not find much documentation on Stripe to suggest testing methodologies for recurring payment).
I do not agree much with this approach, because it stretches the testing of my code to more than a week, maybe even two, but in normal conditions I might finish that testing within a couple of hours.
I think one of the following two approaches would be sufficient to do my coding/testing.
Find a way to make recurring subscription interval happen on shorter custom periods, such as every 15 minutes, or every 10 minutes.
A better solution is to make recurring subscriptions trigger on demand. That is, I create a subscription, and then I would update the date for the next renewal manually to a custom value, such as "1 minute in the future" or "30 seconds in the future" which would trigger the payment attempt.
Is there a way of doing any of those two options in Stripe? If neither is a viable option, how do I test recurring payments efficiently.
Thanks.
Our solution was to reset the billing cycle of the subscription.
open the subscription in Stripe
click "Actions" in the upper right
select "Update Subscription"
be sure to switch off "Prorate changes"
scroll down and open "Advanced Options"
check "Reset billing cycle"
and finally... Update Subscription
This will trigger a new subscription payment and all the associated webhooks.
Simple method
Definitely #Marc found the great option for arbitrarily subscription renewal. The same action he described in this answer can be done programmatically or with the Stripe CLI:
stripe subscriptions update sub_id \
--proration-behavior=none \
--billing-cycle-anchor=now
This command generates the following sequence of events:
charge.succeeded
invoice.finalized
invoice.created
invoice.paid
invoice.payment_succeeded
customer.subscription.updated
payment_intent.succeeded
payment_intent.created
Advanced method
The use of test clock gives more opportunities to verify your system's behavior. It is possible to attach test clock not only to the Subscription object.
So I would start with their testing documentation It walks you through the process.
it seems that you can trigger events on the fly with CLI commands.
Also look at the Webhook Monitor
I have a website coded in PHP that uses paypal buttons/IPN for subscriptions.
The method is limited and I need to replace it with the REST-API.
What the system needs to do:
Accept new user recurring-payment subscriptions
Be able to change plan pricing for new users
Be able to change plan pricing for existing users
Change subscription plans mid-subscription(If a user upgrades from pro to master the price goes up, and the opposite way it goes down).
The price difference between packages is 5$
Give periodic discounts for a limited amount of months.
The questions:
1.) What is the equivalent of recurring-payments in the PHP-API or REST-API? (I'd rather it auto-charges and notifies my IPN if possible)
2.) How can I automatically refund/charge an additional amount when the user upgrades/downgrades in the middle of a month?
3.) Is there a standalone PHP control-panel that can connect to the paypal API to manage the subscription packages + sales?
Thanks in advance!
If you are looking to use REST APIs, the best place to start is going to be at the REST API docs. For your situation, you can use the vault to set up a recurring payment system. You could also use the future payments API, but you will need to make sure you buy DPRP for your account. Contact PayPal Customer Support to enable DPRP.
With the Vault API, you can just create one time payments over and over with the token you get when storing a credit card.
There is an in-depth walkthrough using the SDK on the PayPal PHP SDK Wiki.
To do refunds, you can use the Refund REST API. All this assuming that you would be writing scripts to detect your user downgrading/upgrading. You would just need to store the amount they are paying each month in your DB.
There are some shopping carts out there that are implementing REST APIs. You might need to google search for something like that.
Hope that helps and gets you started in the right direction!
So I am dealing with Authorize.net's ARB, and I have a situation where the user is applying for usage of our service for eg. 3 months. We charge the user for this period - 3 months, but we don't make a subscription immediately. The thing is, we don't want to automatically charge them again once the membership expires after 3 months, but only if they go to account settings and set that option (extend membership automatically). So if they don't select it, there is no need to establish a subscription, so that's why we aren't doing it in starting point, once the user applies for this service.
So the question is, should I create a new subscription once user selects "Yes" for that option, and delete the subscription when he selects "No" ?
Is there another way to do it?
It's really hard to find some answers by Google, and I was hoping someone with more experience will have an answer here.
Thanks in advance.
When the user selects "Yes" for the new subscription just create a new ARB subscription with a start date of three months past their three month trial period. The three month subscription will run its normal course and terminate after three months. Then the new subscription will start at that point.
But here's the catch with that solution: you need the customer's credit card information in order to recreate another subscription. Unless you store it somewhere (bad idea) you can do that. So you would need to ask for it again. That's a large hurdle to overcome and will negatively affect conversion rates.
Alternatively you can automatically create the three month subscription at the point where the user starts their three month trial. As they approach the end of the three month trial you should make them aware there subscription will automatically start unless they cancel it. This solves the creation of the subscription problem but isn't very popular with users as nobody likes being automatically enrolled in a subscription.
Third option is to use Authorize.Net's CIM API to create a payment account for that user. Then you can charge against their card whenever you want. The problem with that is CIM does not support subscriptions. So you'd have to write your own subscription engine to make this work.
So there is no ideal solution for this. You just need to pick the one that you think works best for you.
The situation is like this,
I have three kind of user registration on my site
$20/month
$30/month
$40/month
now, suppose a user registers with $30 amount and takes the 2nd registration...
next 2 months his $30 per month were deducted as per the recurring payment of paypal...working fine .:)
Now, he wants to upgrade to $40 i.e 3rd membership , so from next month his amount deduction should be $40... How to update paypal for this change in amount..
I DON'T WANT TO GO TO PAYPAL'S SITE FOR THIS...
Is there any API for this purpose.......
Any help would be appreciated....
First off, Paypal's API is not a simple or easy thing to use, but what you're asking can be done. It is simply a matter of canceling the existing 'recurring payment profile' via the API, and starting another recurring payment that ends at the same time.
The API methods themselves change depending on which system you are using. At my company, we use Paypal Website Payments Pro. This has a specific set of functions to perform actions. Without knowing which system you use, however, we can't give any further advice.
The below link shows a number of the methods for the different Paypal API's. Do your research, and try to ask specific questions. :)
https://cms.paypal.com/us/cgi-bin/?cmd=_render-content&content_ID=developer/howto_api_reference
Daniel Moniz
I was able to do this, but first, this caveat from PayPal should be noted:
Note: For recurring payments with Express Checkout, the payment amount can be increased by no more than 20% every 180 days (starting when the profile is created).
Since I'm not using Express Checkout, POSTing this worked for me to change an amount from $75 to $200 (the credentials are fake):
TRXTYPE=R&TENDER=C&PARTNER=PayPal&VENDOR=Acme&USER=Acme&PWD=a1b2c3d4
&ACTION=M&AMT=200.00&ORIGPROFILEID=RP0000001234
The other caveat is that this is only one of I-don't-know-how-many APIs and I-don't-know-how-many-types-of-accounts (in this case Payflow) that PayPal has, and I don't know if something similar works for all of them. The above code is actually copied almost verbatim (credentials and amount changed) from https://developer.paypal.com/docs/classic/payflow/recurring-billing/.
I have finally got my paypal system working using IPN and a reservation system to ensure that two people do not buy the same product.
The problem is, the reservations last for 10 mins on my application. If a user reserves the product the 'timer' starts, he clicks pay and ends up on paypals website. He then leaves the computer for 10 mins and comes back. He then buys it. By now though the reservation is up and it is possible that someone else could have already bought it.
Is it possible to send a time limit with the paypal IPN request to stop this happening?
As far as I know, you cannot specify that a transaction has to close within a certain amount of time with paypal.
However, I see two options you can use:
Offer a full refund if they purchase and the product is not available. You would check during the ipn notification of the purchase and if it is not available, then refund. You might be penalized by paypal if this happens a lot, but I don't have a lot of experience with offering refunds.
You can specify that the button needs to check inventory see "Step 2 – Tracking Inventory With Your Buy Now Button" in the standard payments guide. Once the product becomes sold out, you use the api to notify paypal the inventory is zero (if there is an api, you might have to use the website for this), and they should be able to notify the user there is zero inventory. I don't have experience with this either, but it seems more complicated than #1, and I would probably go with #1 if this didn't happen a lot. I think in the end you still end up having to issue a refund if the user goes through with the transaction even after seeing there is zero inventory, but I'm not sure about the wording in the docs.