I am testing PayPal's subscription process by using PayPal's sandbox, but the thing is, the minimum period is 1 days, and I want to perform multiple tests until I get everything right, I surely do not need to wait for a period of 1 day to test my code changes.
So there surely should be a way for me to trigger subscription renewal, or some way to work around it.
I've tried to set subscription period to 0.01 days, and PayPal would not accept that. So any suggestions?
Thanks
Related
I'm using stripe's php wrapper for its api to manage customers subscriptions.
We need to have a pause option for subscriptions which range in time from 3 months to a year. The pause option would be one of three options 1 month 3 months and 6 months. The method I was using was to set a trial version for their Stripe account for the duration of the pause but the problem with that is once the trial ends they are charged, albeit at a prorated amount, but thats not the type of pause we are looking for. We need it to our customers seem actually paused then when it un pauses it has the same amount of time on it left as when they paused it with no upfront charge. I have been trying to figure out how to do this but cant figure out a way to have it all happen on stripe. any of my other ideas involve having a cron job or some kind of time trigger on our server to handle the end of their pause period.
example of what I have so far:
pause_sub($sub_id) {
$sub = Subscription::retrieve($sub_id);
$sub->trial_end = time() + (31556952 / 12);
$sub->save();
return "Subscription Paused";
}
Maybe there is a way to use a stripe event with a webhook when the trial ends?
Thanks for the help.
With your approach, you need to disable proration as it is enabled by default when you modify a Subscription: https://stripe.com/docs/api/subscriptions/update#update_subscription-proration_behavior
There is no native "pausing" of Stripe Subscription but you can use alternative approaches to get the desired behavior (like switching to a free plan): https://stripe.com/docs/billing/subscriptions/canceling-pausing#pausing-a-subscription
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 setup a PHP script on a cron which contacts Braintree via the API to look up the status of each subscription that we have on file. We then update our local records based on the customer's subscription status. Because I can manually cancel a subscription from the Braintree control panel, I have been able to test that my script can detect canceled subscriptions.
However, I can't find any way to test a past-due status other than to wait for the billing cycle to go 'round. Because the minimum length of a billing cycle in Braintree is one month, this makes debugging my script very difficult.
I know that in theory I should just see a different string for the status of the subscription, but I'm looking for a reproducible way to simulate past-due status, along with a positive balance and value for daysPastDue.
Can anyone help?
$BT_subscription = Braintree_Subscription::find($BT_subscription_id);
if ($BT_subscription && $BT_subscription instanceof Braintree_Subscription) {
if ($BT_subscription->status == 'Past Due' && $BT_subscription->balance > 0) {
// ...
I got the following reply from Braintree support about this issue:
Because our sandbox environment is meant to replicate our production environment there is no way to force a subscription to past due. However here is a little work around that might make this testing easier:
To put a subscription in the Past Due status in the Sandbox, you can create a subscription with a trial period of one day and a price of $2000. Then, when the one day trial expires, it will trigger a transaction create that will fail because of the dollar amount.
The $2000 price tag is likely for the Test Amounts for Unsuccessful Transactions to trigger the credit card payment to fail. I have setup a test, and will edit this if the test proves unsuccessful.
Adding on to Tyler V's response, and this is still the only way to test it, unfortunately.
From support:
Thanks for reaching out, and appreciate your patience. Using a sandbox
account, the shortest amount of time you can simulate a result will be
1 day. Use the following example to create a Past Due status:
Create a plan with a 1 day trial and $2000 price Create a customer
with a credit card Create a new subscription using the plan and
customer The first charge attempt will be after 1 day (when the trial
expires) and will fail The automatic retries will be at +10 and +20
days of the subscription going past due Please see the following page
for Sandbox test values. I would recommend that the you create a LOT
of these at one time so you have multiples to work with; otherwise
you’ll have to wait a day for each new one they create to move into
past due.
#Tyler V.
When creating a new subscription, you can set first_billing_date to one day ahead
You should enable Webhook, store the message, and replay it by using postman.
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 am working on an application that provides a 30 day trial, then the option to have a monthly or yearly subscription (at two different prices).
I've used a lot of the info provided by John Conde on his site (thanks John), but want to be sure I've got the right idea about how all this works - my first time doing anything with Authorize.net or subscriptions...
So if I have a 30 day trial, and someone decides they want to pay today, they should not be billed for 60 days. I set the start date ahead 60 days, but should I see any kind of charge in Authorize.net showing it's pending?
Next, is part of the ARB service that it "watches" for the renewal, or am I supposed to do something to trigger the check on a regular basis. I'm pretty sure that's what ARB is, and I don't need cron to check each day, but I'd rather ask a dumb question now rather than have a bunch of missing charges later.
Finally, what information would you recommend I store in my local DB and what should I let the ARB service capture. Currently, I'm storing what the subscription item is, who the person who is making payment is (by id), the name on the card, the last four digits of the card in case they want to reference what was used, the expiration date of the card, so I can look for pending expirations (unless this is part of ARB as well) and the date the subscription starts, ends.
Any additional info is appreciated.
So if I have a 30 day trial, and
someone decides they want to pay
today, they should not be billed for
60 days. I set the start date ahead 60
days, but should I see any kind of
charge in Authorize.net showing it's
pending?
Use the AIM API to charge their initial payment and then set the start date in ARB to be in 60 days (when their first payment is). You won't get any notice that the subscription is "pending" but if a subscription ID is returned to you by the ARB API then it's safe to assume that first payment will be attempted in 60 days.
Next, is part of the ARB service that
it "watches" for the renewal, or am I
supposed to do something to trigger
the check on a regular basis. I'm
pretty sure that's what ARB is, and I
don't need cron to check each day, but
I'd rather ask a dumb question now
rather than have a bunch of missing
charges later.
You don't have to do anything. The "A" in ARB stands for Automated and it is completely automated. Once a payment is scheduled it will run automatically until the subscription ends, you cancel the subscription, or their card expires and you don't update it before the next scheduled bill date.
Finally, what information would you
recommend I store in my local DB and
what should I let the ARB service
capture. Currently, I'm storing what
the subscription item is, who the
person who is making payment is (by
id), the name on the card, the last
four digits of the card in case they
want to reference what was used, the
expiration date of the card, so I can
look for pending expirations (unless
this is part of ARB as well) and the
date the subscription starts, ends.
Send as much information to the ARB API as you can. It makes researching transactions in the Authnet control panel much easier as you can compare what you have captured to what they show in their transaction history.
It sounds like you're storing information that will be useful to you. I'd encrypt anything credit card related as to make it less useful if your DB gets hacked. You store enough information that a hacker could use it to convince your customers that they have their credit card number and then things get really ugly.
Well, in general you should avoid storing CC info (for security reason), so keeping everything at ARB would be better.
You should schedule the payments right when the user registers and set the startDate in the SOAP-call to 60 days later. Store the transaction key or however they call, so you can cancel the subscription at ARB anytime. If you do it that way, you can avoid handling payments at all and you just need to handle subscription and unsubscription.