Upon cancel, I want to know how much time is left on the subscription's current billing cycle.
This question -- paypal-ipn-get-subscription-end-date-recurring got answered with a scenario where, upon the end of the cancellation period, a paypal event is sent at the end date. In my case, however, I want to know in advanced how much time is remaining and record a future date (like a credit) and allow the user to use that up that time or give them an advance on their signing up again with another payment method (delay their next bill for example).
There is a final_payment_date under the deprecated billing agreements API: https://developer.paypal.com/docs/api/payments.billing-agreements/v1/ .. They say to use the subscription's API, but there is no end date available. It is possible to use the subscription API to set things up and still use this API.
Unfortunately, because I don't see a non-deprecated end-date anywhere I think I may need to dive into the implementation here:
https://developer.paypal.com/docs/paypal-payments-standard/integration-guide/subscription-billing-cycles/?mark=cycle#
Paypal's Monthly example from the link above. "[...] signs up on Tuesday, December 30, the subscriber is billed as follows:"
Tuesday, December 30 = $25.99 USD
Friday, January 30 = $25.99 USD
Sunday, March 1= $25.99 USD
Wednesday, April 1= $25.99USD
I'm close, instead of ending up on March 1st, I end up on March 2nd:
> d=new Date('2017-12-30')
2017-12-30T00:00:00.000Z
> d.setMonth(d.getMonth() + 1); d
2018-01-30T00:00:00.000Z
> d.setMonth(d.getMonth() + 1); d
2018-03-02T00:00:00.000Z
> d.setMonth(d.getMonth() + 1); d
2018-04-02T00:00:00.000Z
In any event, looks like I need to save the subscription's first billing time and as long as the plan is still active and current on payments, I'll have to calculate when their next bill will be.
BILLING.SUBSCRIPTION.CREATED (webhook received)
Status ACTIVE resource id I-79CLVAS5XM95
As a point of reference, the BILLING.SUBSCRIPTION.CREATED create_time is 2020-06-05T19:45:08.868Z.
Save resource.id = I-79CLVAS5XM95
Also save a date here, will use it to calculate the billing cycle
resource.billing_info.next_billing_time = 2020-06-05T19:35:10Z
Or resource.start_time = 2020-06-05T07:00:00Z ?
Lookup resource.plan_id => https://api.sandbox.paypal.com/v1/billing/plans/P-1BC0896985601515LL3FNLCQ
Get billing_cycles.frequency.interval_unit = DAY|WEEK|MONTH and interval_count. For example, if the interval_unit is DAY with an interval_count of 2, the subscription is billed once every two days.
plan.billing_cycles
[{
pricing_scheme: {
version: 1,
fixed_price: { currency_code: 'USD', value: '0.01' },
create_time: '2020-05-24T20:14:02Z',
update_time: '2020-05-24T20:14:02Z'
},
frequency: { interval_unit: 'DAY', interval_count: 1 },
tenure_type: 'REGULAR',
sequence: 1,
total_cycles: 0
}]
This question -- paypal-ipn-get-subscription-end-date-recurring got answered with a scenario where, upon the end of the cancellation period, a paypal event is sent at the end date. In my case, however, I want to know in advanced how much time is remaining and record a future date
To know in advance, use resource.billing_info.next_billing_time, not the resource.start_time (checkout time)
The example you quoted above:
Tuesday, December 30 = $25.99 USD
Friday, January 30 = $25.99 USD
Sunday, March 1= $25.99 USD
Wednesday, April 1= $25.99USD
Is due to February's shortness. February doesn't have a 30th to charge on, so PayPal opts to push the subscription forward to March 1 to keep everything roughly 30 days apart. This is explained in the documentation you linked to.
Related
I am building a financial model and adding loan payments, and want the payments to start on a conditional start date.
I can calculate the PMT amount for a loan, but cant seem to get the payments PMT to show up in the specific start date (month) and to end when the balance is 0.
[1]: https://i.stack.imgur.com/4VWzk.png
I have a start date in Column J and calculated the payment, but I get an error message.
I tried the following, but not sure where I am going wrong.
J61 pmt start date either Jan 1 or June 1 2023
S2- start of the month
S4- end of the month
PMT(rate, nper, pv, [fv], [type]) this works
NPER= number of payments
=IFERROR(IF(AND(J61>S3,J61<=S4,1,0)),PMT(G61/H61,I61*H61,F61))
Not sure how to incorporate the ending balance into this formula.
End date with Balance equals= 0
Since your financial model has monthly granularity of calculations, it is not clear how you want to allocate the payments for loans that have intra-month start dates.
Here is a very simple solution that will not allocated pro rata for the days of a month, but allocated the total monthly payments starting with the month of the start date.
=(S$4>=$J61)*(S$4<=EDATE($J61,$H61)-1)*$K61
Which looks like this
So, as you can see in the screenshot, although the start date for the 1st loan is the 31st of January, there will already occur the full PMT amount for the month of January in the timeline.
Simple questions, but I can't seem to find the answers in PayMill's API documentation or FAQ:
If a payment subscription is classed as monthly, does it poll for the funds every 30 days or on the anniversary of the month, i.e. set up on 15.4.2014, next payment 15.5.2014?
If it polls on the same date every month, what happens if the subscription was set up on the 31st of the month, i.e. on a date not present in February, April etc?
Thanks.
On the same date. If the interval is 1 MONTH and the first payment occurs on 15.4.2014 the next one will be on 15.5.2014. Note that you can also specify a weekday, in that case it will be the next weekday (e.g. Monday), either the 15.05.2014 (if it's a Monday) or the first Monday after 15.05.2014
It will probably be on the next day (1 March instead of the "missing 31 February". It will definitely not be skipped. If the exact behavior is crucial for your business, please contact the PAYMILL support to seek a definite answer.
How can I start charging a user the user immediately for a PayPal billing agreement?
Here's what I've got so far.
Create a Billing Plan (POST .../payments/billing-plans/)
Make it active (PATCH .../payments/billing-plans/)
Create a Billing Aggreement (POST .../payments/billing-agreements/)
Send user to approval_url, user approves, redirected to return url
Execute agreement (POST .../payments/billing-agreements//agreement-execute)
This all seems to work, but I want to charge the user right now and every month in the future. If I set start_date to now in step 3 I get an error, it must be in the future. If I set it in the future the user is not charged.
Do I need to 'Set outstanding agreement amounts' then 'Bill outstanding agreement amounts' for the initial payment?
Also, what about monthly payments, do they require some action or do they just happen as specified in the Billing Plan?
Update
I'm testing this around 2014-09-16T20:06:30+0000
If I send start_date as the current UTC time it get an error at step 2 telling me it must be in the future.
If I send the current date +30 secs or +2 hours I get through to step 5 which returns a 400 response: UNKNOWN_ERROR "An unknown error has occurred"
If I send the current date +4 hours it all works. The current UTC time is 8pm so adding 4 hours means the start_date is tomorrow.
Does this mean I can't charge the user today? Does the start_date have to be in next day or even the next business day?
I've talked to a PayPal rep and found that start_date must be tomorrow or later. They are going to add this to the docs.
If you want to start monthly billing immediately you might be able to do it by setting the start date to be in one months time and charging a setup fee to cover the first month. I haven't tested this as it's not what I want.
First payment for agreements will be billed right on specified start_date. The subsequent amounts are also taken automatically by PP. You need to work with the BillOutstandingAmount calls only if PP failed to pick the payment on the renewal date.
The problem I faced when developing with their RestAPI was specifying a wrong timezone. Maybe this is the same for you. Make sure the proper timezone is specified in your start_date (with all dates given to PP in fact)
Dates should be in this format: yyyy-MM-ddTHH:mm:ssZ
ex. start_date = 2014-09-16T09:20:00-0400
IF you want to make sure Paypal accepts the date as being valid, just add a few seconds to it.
Let's say you are in Java, you can do something like:
private String getPaypalDate()
{
DateFormat df = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ssZ");
// Add 30 seconds to make sure Paypal accept the agreement date
Date rightNow = new Date(new Date().getTime() + 30000);
return df.format(rightNow);
}
I used this date format working.
$time = time();
$startDate = date('Y-m-d\\TH:i:s\\Z', $time);
I can't replicate, actually. I stumbled on this thread when getting the error due to setting it to moment.now(). But setting it to even 5 seconds in the future works a-ok. I'm using JavaScript, "start_date": moment().add({seconds:5}).format() and that checks out fine. Moment.js will set TZ to UTC when formatting as such, so it's gotta be a timezone thing on your end?
It looks like the payments just process based on the date being before or after 07:00 UTC of the current date.
For example. The current date time is 2017-05-04T04:50:00.00Z I set my start date to be the current UTC date time plus 30 seconds. Because the agreement date is set to a value greater then the current date time the API doesn't throw an error, but it DOESN'T set your time to be what you specified. Instead it sets it to 2017-05-04T07:00:00Z.
Now, if you have the same date time of 2017-05-04T04:50:00.00Z and instead of adding 30 seconds you add 24hrs you'd think that your time would then be set to be 2017-05-05T04:50:00.00Z. But no, the time will be set to 2017-05-05T07:00:00Z.
So it seems like these just process everyday at 07:00 UTC and you can't specify anything but the date.
For monthly recurring payments, how long is a month defined to be? I need to be able to independently track subscription end dates on my web service and I'd like to be consistent with PayPal.
As said on PayPal's documentation:
How Subscriptions with Monthly Billing Cycles Work
For monthly billing cycles, recurring payments are collected on the
same day of the month. If the initial recurring payment falls on the
31st, PayPal eventually adjusts the billing cycle to the 1st of the
month. If the initial recurring payment falls on the 29th or 30th,
PayPal adjusts the billing cycle to the 1st of the month on the
following February.
When Monthly Recurring Payments Are Due and Collected on the 31st
The subscription terms are:
$25.99 USD a month; the subscriber signs up on Thursday, July 31. The
subscriber is billed as follows:
Thursday, July 31 = $25.99 USD Saturday, August 31 = $25.99 USD
Wednesday, October 1= $25.99 USD Saturday, November 1= $25.99 USD and
so on... Notice that no recurring monthly payment was collected in
September, but recurring payments were collected roughly every 30
days.
When Monthly Recurring Payments Are Due and Collected on the 30th
The subscription terms are:
$25.99 USD a month; the subscriber signs up on Tuesday, December 30.
The subscriber is billed as follows:
Tuesday, December 30 = $25.99 USD Friday, January 30 = $25.99 USD
Sunday, March 1= $25.99 USD Wednesday, April 1= $25.99USD and so on...
Notice that no recurring monthly payment was collected in February,
but recurring payments were collected roughly every 30 days.
Read more at https://developer.paypal.com/webapps/developer/docs/classic/paypal-payments-standard/integration-guide/subscribe_buttons/
I got confused about some issues:
1: The one month duration of auto-renewable subscriptions is 30 days or does it depend on a natural month?
Because I can only test in sandbox mode，so the duration is just several minutes...
Maybe Apple just simply calculates it like this: 2013\01\15 -> 2013\02\15 -> 2013\03\15. If so,the second issue comes up
2: For example: I buy a monthly auto-renewable subscriptions at 2013\03\31 ,because 2013\04 only has 30 days, then what is the expires_date of my subscriptions? 2013\04\30 or 2013\05\01 or other date ?
It's adding 1 month, not 30 days. The number of days in 1 month varies. So purchasing a subscription on 3/31 would end on 4/30.
You can use NSDate, NSCalendar, and NSDateComponents to add a month to a date and see how long it will last. More info here: Modifying NSDate to represent 1 month from today
I can confirm this from my own app's data on both iOS and Android.
If someone purchases a monthly renewing subscription on, for example, the 15th of one month, then it will renew on the 15th of the next month, irrespective of how many days were in the month.
If someone purchases the subscription on the 31st of March, then it will renew on May 1st (because April has no 31st day, the renewal date will jump to the next available day in the calendar year - this also applies to February in a leap year, etc).
Given this, and assuming your app's primary income is from subscriptions, over time you should expect to see lower than average sales on the 31st of any given month because there won't be as many renewals. But it is no cause for concern as it is counteracted by the fact that you should expect to see higher than average sales on the 1st of any month that follows a long month anyway. Don't be dissapointed if you check your stats on the 31st of any month.