I'm maintaining a web application which deals with some kind of subscriptions. Users can to renew their subscriptions from 2 months before expiry (not earlier than that). Sometimes user does not renew before expiry and get grace period which is of 3 months. Now he can renew in these 3 months of grace period.
Now the problem part. In the previous transactions of renew requests I have to show what was the offer period for that particular request (subscription start and subscription end period if renew was granted). Things are pretty simple if user renews before expiry, but I'm not able to get things straight if there is grace period specially when the subscriptions is expiring in last months of the year. Also there sometimes calculations go haywire when subscription is ending in jan or feb.
All this is happening because offer period is not saved with the application anywhere (I don't know why). so if subscription is ending in 20 October 2008 and renew application is submitted in 16 January 2009 (because of grace period) the offer period should be 21 October 2008 to 20 October 2009.
How can I calculate correct offer period based on renew request submission date for old renew applications?
EDIT:- Now is 2010, suppose user is viewing past transaction from year 2009, when he submitted request to extend subscription from 21-10-2008 to 20-10-2009. But he has got grace period and requested renew on 16-Jan-2010. As I don't have 21-10-2008 to 20-10-2009 stored anywhere I have to calculate that it was 21-10-2008 to 20-10-2009 when the request was logged. And this is where I'm having trouble.
#TheVillageIdiot,
(A)> Now is 2010,
So far so good . . .
(B)> suppose user is viewing past transaction from year 2009,
Yup, I’m with you . . .
(C)> when he submitted request to extend subscription from 21-10-2008 to 20-10-2009.
So you can see somewhere in the database or in a log file that the subscription was from 21-10-2008 to 20-10-2009, right?
(D)>But he has got grace period and requested renew on 16-Jan-2010.
Ok. But this transaction date (16-01-2010) should not matter for the actual begin and end of the subscription. It is part of a constraint on when a “renew” can occur. (The other part of the constraint is the 2 months prior to expiry that you mentioned before.) Therefore you should never need to consider when a person renewed to know what the subscription begin and end dates are.
(E)>As I don't have 21-10-2008 to 20-10-2009 stored anywhere
Wait, then how in (C) do you know the subscription was from 10/08 to 10/09????
(F)> I have to calculate that it was 21-10-2008 to 20-10-2009 when the request was logged. And this is where I'm having trouble.
Yeah, unless you have it stored somewhere; I don’t see how you would know it was from 21-10-2008 to 20-10-2009 or 25-10-2008 to 24-10-2009 or 21-10-1908 to 20-10-1909.
I really think above in part (C) you must have the subscription begin and end dates around somewhere and as I commented in (D) you should be able to ignore when the actual renew request transaction was made in order to calculate the beginning of the next term.
Ok, now, I am going to assume that you truly do not have the subscription begin and end dates for past subscriptions stored somewhere. (Which I find really hard to believe.)
Here is a possible answer to your question:
You do have the customer’s current expiration date (otherwise you would not know when to begin the prior two month renew window or the three month grace window). So, given this current subscription expiration date you could work backwards on a year by year basis. In this way, you would be able to reconstruct all the customer’s past subscriptions.
However, there is a problem with this, if the customer failed to renew during the grace period then a new subscription probably began with a gap in time from the one prior.
Anyway, double check to ensure that there is no possible way to determine the subscription begin and end date. I think you will find them somewhere and should be able to get them into your database.
Good Luck.
Related
I'm one of many who received a google V2 reCAPTCHA usage limit reached with a 90 day notice to reduce usage under the 1M free per month by purchasing enterprise or having limits enforced (message on your site stating it's "over limit" and every request passing).
However, it's now 105 days since that message, FINAL NOTICE was on June 2nd, and the limits aren't being enforced. It's July 13th, and I'm at 1.3M captchas for July.
Has anyone received a limit reached email that has not had them enforced after the period?
When does the limit reset each month? I'm assuming the 1st of the month, but I could be wrong.
PS: I'm not sure where else to ask this, but if this is the wrong forum I can move my question.
I'm developing an application, which needs to use calendar and I've decided to try a ready-made solution - Google Calendar API. I'm making calls from my backend to google and I only store calendars' and ids in my database, everything else is stored in google. So I'm writing a proxy basically and everything is going ok, but I've bumped into this article https://support.google.com/a/answer/2905486?hl=en, and now I'm really worried about those "short periods of time" in exceeding limits. I haven't found more accurate numbers. Well, if those "short periods of time" are ~1h, then I'm in the trouble and I need to implement my own calendar system. Can anyone dispel my doubts? This is not a pet-project.
Answer:
There's no public official information regarding the exact period this is referring to.
Nevertheless, after some testing, it seems like the short periods of time are longer than what your workflow would require.
Research:
Since the limit that is troubling you is calendar creation (from Avoid Calendar use limits):
If you create more than 60 new calendars in a short period, your calendar might go into read-only mode for several hours.
I did some tests with a Workspace account, in order to see what's the maximum rate of calendar creation that won't result in this limit being exceeded.
More specifically, I tried creating calendars periodically, with several different periods, ranging from 5 seconds to 15 minutes.
For most of these periods (from 5 seconds to 10 minutes at least), the following exception started showing up after creating 40-something calendars approximately:
You have been creating or deleting too many calendars or calendar events in a short time
After this, no more calendars could be created for some time.
For 15-minute period, I got the error after creating around 80-something calendars, so I guess the maximum rate of creation is close from there (1 calendar created every >15 minutes). Since this rate is not disclosed, though, it could change without notice, so take this with a grain of salt.
The original poster, GorgeousPuree, also made some testing, with results in accordance with what I got (see comment):
I also made my expirements and I've got a timeout after 25 calendars in 1 and 3 minutes intervals.
Conclusion:
In any case, the short period seems to be way too long for the worst case scenario:
60 calendars in 5 mins
I'd like to setup a Microsoft Flow trigger in Office 365 so that if I get an email from a specific set of people after hours, or on the weekend that I'd get a notification from the app. I've got the people portion figured out, and I see they have an "equals" condition for the receive time, but how can I filter by day / time range?
I haven't done this before, but look into the dayOfWeek() and startOfHour() functions.
You can figure out if its a weekend using dayOfWeek(), and for the weekdays use startOfHour() to know if the time is greater than or less than your preference.
-Chris
I want to integrate recurring payment using Payeezy in codeigniter. I have implement the single time payment using curl and now i want to recurring payment with acknowledgement to update my DB.
I created a WordPress plugin for Payeezy that also handles recurring. You should be able to use the underlying PHP code for CodeIgniter.
https://wordpress.org/plugins/wp-payeezy-pay/
I can explain the process that will get you the least PCI compliance issues, and that's the token-based API.
1. Generate Token in Payment Form
So basically you'll use the Javascript API to generate your authorize token. An authorize token doesn't charge the card. It's for validating the card and returning a token for better PCI compliance. This API source code and explanation is here:
https://github.com/payeezy/payeezy_js
2. Post Form To Your Server for the Curl Call to FirstData
Then, once you have this token, you post it back to your controller file with a standard form post, but remove the name attribute on your credit card number and credit card CVC fields so that these do not post to your server. Note that you'll need to store this data (but not card number and CVC) because on refunds (and subscription cancellations) you'll need to reply back with the last purchase token, cardholder name, card type, card expiration date, amount spent, and currency code. You may wonder why FirstData/PayEezy is asking you to store cardholder name, card type, and card expiration date. Well, there's a perfectly good explanation for that. Your call center may need that detail for troubleshooting an issue over the phone with a customer. Also, you need that for refunds. And, most importantly, if you're doing a recurring subscription payment, your code needs to look at the expiration date ahead of time before charging because the API call will fail if the card is past expiration. Last, because you're not storing the credit card number and credit card validation (CVC) code, you're going to be in stronger PCI compliance.
From there, since you are already familiar with the Curl process for a single-purchase, it's just a minor single field change (transaction_type becomes 'recurring') in the Curl to do the recurring. For anyone not familiar with the Curl process, it's explained here:
https://developer.payeezy.com/payeezy-api/apis/post/transactions-4
Also, for those unfamiliar people, you'll need to read up on how FirstData/PayEezy wants you to send in the Curl request with a special header that includes Content-Type: application/json, apikey, token, Authorization, nonce, and timestamp. You can see more detail about that here:
https://github.com/payeezy/payeezy_direct_API/blob/master/payeezy_php/example/src/Payeezy.php
(What I did to make that code simpler was intercept the Curl calls from that script into a log file so that I could make it much more straightforward in a single function instead of breaking it up into all these little functions. That made it far easier to understand what was going on.)
3. Switching Curl Call for Recurring Payments
So, as you discovered in your Curl call, you saw how to do a one-time purchase by setting the transaction_type to 'purchase'. For doing recurring, you set transaction_type to 'recurring'. You have to do that from the start. So, if I'm selling something for $29.99 monthly, the very first month charge needs to still be set to type 'recurring', as would any subsequent month.
4. Your Responsibilities for Recurring Payments
Now, this is where everyone gets hung up because it's poorly documented unless you check the PayEezy Developer Support Forum. For subscriptions, PayEezy doesn't have a system for setting payment plans with varying durations, nor setting up automatic (set-it-and-forget-it) subscriptions for you. (I think I read that they have something experimental on Apple Pay, but nothing else yet.) So, to achieve this, you have 2 choices:
Use Chargify.com. Unfortunately, though, this increases CPA (Cost Per Acquisition) of your product or service. You'll have to factor that in if you want to use that. This basically is a SaaS service that you send the transaction to and they handle the automatic subscription plan for you against FirstData/PayEezy.
Roll your own cron job solution. To do this, you basically take the Curl code for a single transaction, and change the transaction type from 'purchase' to 'recurring'. (Do that from the start -- don't start with 'purchase' on a recurring charge.) From there, it's up to you with your own cron job to check for product or service expiration terms, and then send the API call back off to FirstData/PayEezy for charging that card again with the 'recurring' transaction_type.
On either of those options, the customer never gets asked to enter in credit card data past the first time unless their card expires or unless you have some problem billing that card (like insufficient funds).
Of course, doing your own cron job route for the recurring payment has implications you'll need to prepare for:
Add some failsafe code so that you prevent the possibility of duplicate transactions, such as a database field.
Add some failsafe code such that if you have cancelled a subscription, you won't charge them again.
Add some failsafe code such that if they cancel their subscription, yet purchase it again as a subscription at a later time, that you do charge them again and don't block it from your other failsafe code.
Add some sort of grace period on your product or service such that even if you "say" that the term expired, you have like a 2 day grace period so that your API has a chance to do a renewal.
It's probably a good idea to email the customer before their renewal period so that they can make certain they have money in their account and have a way to cancel that charge (like call your office or call center, or have a link to click where you provide a way to cancel).
If their card has expired before the renewal, and you detect that in the warning email that comes before renewal, then you'll want to let them know this.
If their card has been declined for any reason at the point of renewal, then you'll want to let them know this and give them a link to go through the cart again to buy it again, or some other way to save that transaction in your code.
How To Do Subscription Cancellations / Stop Recurring Payments
To stop a recurring payment, you treat it just like a refund on a single purchase, but use the transaction ID of the last purchase. This is documented with this Curl example here:
https://developer.payeezy.com/payeezy-api/apis/post/transactions/%7Bid%7D-0
Look under "Refund" and choose Token.
What was your most serious production bug? This could be any bug you contributed to the making of or solving in a live system.
[moved my response to the answers]
Mine was on my first project out of school, on a large sales compensation system for a software company. We had a bug in the final summation routine which would attempt to subtract any owned money from the next paycheck. In certain situations, where a retroactive computation increased the amount of money owed from a previous month, the debit would be recorded, and then never get reduced from the next paycheck. What might start out as a $3.23 the first month would increase to $6.46 the following month. You can see where this is going. Although we heard of a couple of user complaints early on we dismiss them as "user error" - the sales plans were complex and it was quite easy for anyone to misunderstand what the correct amount was to be paid. But after a few months, the monies that were missing were too large to be ignored - over $2,000,000 in not paid out payroll checks. The code fix was easy, going over months of payroll computations for hundreds of employees, not so much.
I worked on an e-commerce website where the client data was supplied as a CSV dump from a legacy back-end system. We only had a sample data set to work with (despite repeated requests for the full data set) so the first time we saw the full data was on the live site the morning it launched. All the strings were quoted in the CSV file but the numbers weren't. What we didn't realise is that the legacy system inserted a comma for the thousands in larger numbers - so where we expected, say, 1099.99, we got 1,099.99. Of course, the CSV parser saw the comma and took the value as 1. Imagine the client's surprise when orders started to come in for big ticket items which were apparently selling at the bargain price of £1 each. The code was fixed quickly and fortunately their terms allowed them to decline the orders. Lesson learned: never trust a sample data set and don't go live until you've tested with a full data load.
We had an e-commerce system, and when it was moved to the production server (through our super awesome manual copy/paste/edit settings process), the senior developer - the only one with access to the server - forgot to connect the system to the payment gateway. $18,000 worth of sales later, the client notices that their bank account isn't any bigger than when we started.
Process improvements since that day:
Not one.
How we solved the problem:
Told the client to contact all the customers based on their email notifications
I lost some user registration data for about 7 users during a live update to a system I built. That doesn't sounds so bad, except that it was registrations for an $18 billion IPO. We were able to track the information down through the automated emails that got sent out, but there were a few beads of sweat shed over that little hiccup.