PayPlans Rescue Team in Action

Ankit Mathur , 16 June, 2012


Bugs were roaming to eat-up a customer's website. Light of hope & rescue illuminated the site under dilemma when PayPlans team appeared to avenge the situation.

Yes fellows, a single bug can be devastating for your website. Recently, we battled with a serious bug which popped-up for one of the most important and innovative customer of us. Previously, he was handling his memberships with PayPlans 1.4.

  • Scene 1: Butterly Workflow

    During the use of PayPlans 1.4 he assigned certain value of tax on certain number of plans. Some day, he manually changed the tax's value (manually) and continued with his objectives.

  • Scene 2: Ready for Latest Release

    A day PayPlans 2.0 was released. He being delighted and ready to use the latest version, installed PayPlans 2.0 and migrated himself from PayPlans 1.4 to PayPlans 2.0. Obviously, he was expected to migrate (a functionality provided with the latest kit) to this latest version.

  • Scene 3: Migration Ditches

    Intelligently, he completed the migration but encountered with some issues. Furiously, he moved towards our support team and reported the problem which occured on his end.

  • Scene 4: PayPlans' Rescue Team

    As soon as our support team received the notification, they were under action to resolve the bugs which appeared at our customer's end. We found that, the biggest problem which popped-up, was because of some manual changes in tax values made by the administrator. Abruptly, we started working on the issue.

    • We took the customer's database at our local end.
    • Fired lots and lots of test cases so as to provide a more robust functionality.
    • Disabled the Notification of emails so that the customer do not receive any spam emails.

  • Scene 5: Bugs Under Threat

    Few more major bugs were pointed in the migration process which migrates users of PayPlans 1.4 to PayPlans 2.0.

    • Bug Killed (Part I):
      Earlier, irrespective of the expiration type & expiration time every invoice was marked of forever type of subscription. But, now we have fixed the problem and it shows the Plan type according to the subscription done by the user.

    • Bug Killed (Part II):
      Unused invoices were very irritating to us. In case of recurring plan, invoices were sent to the subscribers at every recurrence. From now, we have dumped the unused invoices by selecting those invoices (>1) which have none or confirmed status.

    • Bug Killed (Part III):
      In case of recurring plans, if a customer has unpaid invoices but at later time the customer pays for that, then the previous invoice would be marked as 'Paid' and the newer ones would be dumped.

    • Bug Killed (Part IV):
      Previously, the counter for invoices were not working accurately so, from now we have fixed it and every invoice has appropriate counter.

    • Bug Killed (Part V):
      Modifiers also created certain issues in migration process. Till the bug appeared, we fetched the details from the app's Order ID for the application of modifiers. But, the problem occured when an administrator deletes the app. Thus, we have modified it and now we fetch the required details from the existing subscriptions (not relying on order ids).

    • Bug Killed (Part VI):
      Few times, a problem was noticed that certain payments were not consumed to extend the subscription of the customer but, now we have fixed that error too.

9 nights, 10 days, 25 plus coffee mugs, immeasurable dedication and a lot more things were consumed to solve the issue and rescue-out our precious customer from the dilemma.

Moral:
One should take immense care while manually changing the pre-assigned values of fields, One should not delete any database entry in any case and the most important to follow is that, before engaging yourself in any trouble one should consult PayPlans team so as to avoid any problem from coming into existence.

blog comments powered by Disqus