I have a class for recurring payments for subscriptions and there is a thing that is not 100% clear for me.
If I initialize an order with following params:
Amount: 25$
Initial amount: 0
Period: month
Freq: 3
Does this mean that the user is paying 25$ three months from now or does he pay 25 now with no extra charge (initial amount)?
In other words, what I am asking is - is the initial payment some extra charge or can it be used as a advanced payments for the first cycle subscription, in which case, the params I would need would be:
Amount: 25$
Initial amount: 25$
Period: month
Freq: 3
My understanding is that the initial amount is requested immediately, the reoccurring amount is taken depending on the billing cycle and the start date
this guide might help explain
If the initial amount request fails then the default is to not activate the reoccurring payments.
Related
PayPal describes a "Honor Period" that lasts for 3 days after you authorize or reauthorize a payment, up until 29 days after the first authorization. The docs don't really go into very much detail about this honor period though, just that you should capture within it and that you can restart an expired honor period by reauthorizing.
I have 3 main questions:
When does the honor period start/end exactly? Is it an exact 72 hour window, to the second, from when you auth/reauth? Does it roll over at midnight or something instead? If so, what timezone?
What is the preferred/recommended way to determine if the honor period for an authorization has expired or else determine the expiration time in the first place? Authorizations have a expiration_time field which marks the end of the 29 day window that an authorization is valid for. Is there a similar explicit time field for the honor period? Is it simply based on the update_time field on the latest auth/reauth?
Is there a way to reauthorize before the previous authorization expires? Or more specifically, is there some way to ensure that the payment is always in an honor period, and that there is zero risk of some issue occurring because their funds weren't being held for a short amount of time before we reauthorized them?
The honor period begins the moment a transaction is created and generally lasts 3 days. During this time, captures will generally succeed. During this time, the amount is generally reserved on the customer's funding source, which may be a credit or debit card, meaning they cannot spend it on other things. The exact behavior may vary depending on the funding source and the country due to different implementations and local regulations. The exact time at which an unused authorization "clears" from the customer's funding source and is no longer visible on their statement can also vary, and might take 10 days to no longer show up in some cases.
The rest of the PayPal authorization valid period -- a "post-honor" period, for lack of a better term -- begins on about day 4 and lasts until the end of day 29. During this time a capture attempt can still be made, and will succeed if money is available from the funding instrument. Such a later capture is roughly equivalent to the buyer themselves attempting a new transaction that is of type immediate capture, in the sense that they will succeed or fail for the same reasons.
Reauthorizations to get a new 3 day honor period (but which do NOT restart the 29-day authorization valid period) are almost always pointless. From day 4 to 29 just do a capture when you are ready, and forget you ever heard of the concept of reauthorization.
My question involves parallel (aka split) payments in PayPal's Adaptive Payments API.
I have been trawling various forums for the last hour (doesn't help that all the www.x.com pages are gone), and am unable to find a clear answer to a seemingly simple question about how PayPal's fixed transaction fee is applied in a parallel payment.
I can boil it down to two scenarios, but which is correct: Scenario A or Scenario B?
Many thanks,
Ollie
Scenario A:
Buyer pays $100 (buyer does not pay transaction fees)
Transaction fees for receivers to split = $100 x 3.4% (variable) + $0.45 (fixed) = $3.85
Seller #1 receives $90, less 90% of PayPal's transaction fees (90% x $3.85 = $3.47) = $86.53
Seller #2 receives $10, less 10% of PayPal's transaction fees (10% x $3.85= $0.39) = $9.61
PayPal transaction fees total = $3.85
Scenario B:
Buyer pays $100 (buyer does not pay transaction fees)
Transaction fee for receivers to split = $100 x 3.4% (variable) = $3.40
Seller #1 receives $90, less 90% of PayPal's transaction fee (90% x $3.40 = $3.06 + $0.45 (fixed) = $3.51) = $86.49
Seller #2 receives $10, less 10% of PayPal's transaction fee (10% x $3.40= $0.34 + $0.45 (fixed) = $0.79) = $9.21
PayPal transaction fees total = $4.30
If I recall correctly, the fee is calculated as Scenario A and then split amongst the receivers. You could always test this out on sandbox to determine which method is used.
So after a few inane form letters being sent to me, someone from PayPal responded to my query with the following:
Thank you for contacting PayPal.
From the two scenarios that you have sent Scenario B would apply for the fees on your Adaptive Payment
Scenario B:
Buyer pays $100 (does not pay transaction fees)
Transaction fee for receivers to split = $100 x 3.4% = $3.40
Seller #1 receives $90, less 90% of PayPal's transaction fee (90% x $3.40 = $3.06 + $0.45 fixed charge = $3.51)
Seller #2 receives $10, less 10% of PayPal's transaction fee (10% x $3.40= $0.34 + $0.45 fixed charge = $0.79)
PayPal transaction fees total = $4.30
Thank you for choosing PayPal.
If this is true, I've advised them to make this clearer in their documentation, i.e. that a parallel payment is treated like a series of completely separate transactions, and therefore a full fixed transaction fee applies to each.
If anyone thinks that my advisor from PayPal has it wrong (it's been known to happen...), please speak!
In SetExpressCheckout I have the following values set
'PAYMENTREQUEST_0_ALLOWEDPAYMENTMETHOD' => 'InstantPaymentOnly',
'PAYMENTREQUEST_0_PAYMENTACTION'=> 'Sale'
After a successful DoExpressCheckout, this is some of what is returned
ACK => Success
PAYMENTINFO_0_TRANSACTIONTYPE => expresscheckout
PAYMENTINFO_0_PAYMENTTYPE => instant
PAYMENTINFO_0_PAYMENTSTATUS => Completed
PAYMENTINFO_0_ERRORCODE => 0
PAYMENTINFO_0_ACK => Success
PAYMENTINFO_0_PAYMENTSTATUS -- With InstantPaymentOnly set, will DoExpressCheckout ever return a PAYMENTINFO_0_PAYMENTSTATUS of In-Progress, Pending, Processed or something other than a clear yes or no as to the success?
Basically, since only instant payments are allowed, the only payments that will ever complete will have a PAYMENTINFO_0_PAYMENTSTATUS of Completed the first time around?
ACK and PAYMENTINFO_0_ACK -- Are they linked? Paypal states that ACK "Indicates the Success or Failure status of the transaction and whether any warnings were returned."
Both ACK values will either be Success or Failure? Does that refer explicitly to whether or not the transaction was or will be completed?
Much appreciated,
InstantPaymentOnly blocks non-instant funding sources in buyer accounts (such as echeck payments). This means that you will not get transactions that are waiting on buyer funds movements to complete. But there are other factors which could cause a payment to be pending rather than complete. These other factors may or may not apply to your specific use case, but examples include payments made to you in a new currency which would be held until you decide whether to open a balance in that currency or auto-convert them to your primary currency, or certain fraud filter/fraud detection scenarios.
As for ACK/ACK_PAYMENTINFO_0_ACK, for cases where you are only requesting the one payment (and no additional things like billing agreement signup) I would guess the two statuses will always be equal, but I would advise you to verify with the official documentation.
I'm currently developing a internal application for a company that does patient transport between hospitals and doctor's offices. The module that I'm working on now will give the company the ability to track their various vehicle maintenance expenses and services performed as well as give them the ability to schedule different maintenance services for each vehicle in their fleet.
Different types of maintenance are performed at different time intervals. These are to be repeating events. Some are to be repeated weekly, some monthly, and others every three months.
For the maintenance events that repeat on a monthly or semi-monthly basis I'm a little unsure how I should go about determining days in future months that a event should be scheduled if the date is late in the month and that particular day does not exist a in a subsequent month.
For example, if I schedule a event on January 31st that is to be repeated monthly then I'm unsure where in February that event should be assigned. I would appreciate any suggestions from anyone who has developed a scheduling application detailing how you accounted for these types of scheduling problems.
Looks like I jumped the gun asking this question. I decided to see how Google Calendar handles monthly recurring events. If I add a event for January 31st 2012 and set it as a recurring event then I am given the option to have that event repeat every month that has day 31 or to repeat the last Tuesday of each month.
In my case it would be best to have the event repeat the last Tuesday of each month because the vehicle maintenance shop is closed on Sundays and the maintenance cannot skip a month just because that particular day did not exist in each month.
I'm working on a PHP subscription site and I'm wondering how the different number of days in certain months affect subscriptions?
For example a user signs up the 31 of January for a monthly subscription.
In February there are 28 days so I assume the subscription gets processed the 28th.
My question is what happens the next month. Does the subscription occur the 28th or return to the 31st as when it was first created?
Any help is appreciated, I don't need any code I'd just like to know the logic used. Thanks.
I think it is best that subscriptions be processed on the end of the month. In our company we start processing the subscriptions on the end of the month, we have a batch process scheduled for the end of the month and it processes all the subscriptions.
How these are processed/billed is totally different. According to our policy the new subscriptions are pro-rated i.e., the user is billed according to the number of days that were in the month if the user signed up after 5th of the month. Same is the process of cancellation but it gets prorated if the cancellation is done before 15th of the month.
Lets say the monthly subscription is X, the person subscribes on the Yth day and there are Z days in that particular month.
I would simply charge the guy X*(Z-Y/Z) for that month and bring the billing date to the first/last day of every month after that.