I'm developing application using third party payment gateway to accept bank transfer.
The bank transfer is going to expire within 6 hours if the payment gateway don't receive any transfer from customer.
I want to send reminder email 1 hour before the expiration time.
At the moment, I'm using task scheduling every 15 minutes to check my transaction tables one by one. The transaction is growing and will be million transaction per day in short time.
This approach is not great because cron job is consuming huge memory and not effective. I need some advice to optimize the approach. Can anyone shed the light?
You want an additional table for all "pending" transactions. This way your cron job only reads pending transactions. Once the transaction has been completed, or it has expired, you remove the entry from the "pending" table.
The "pending" table would have only the few fields that necessary to know if the transfer is still pending. When reading this table you would "join" it to the main table to retrieve the rest of the information.
Related
I am building a financial web app, sort of an e-banking application. Whenever a transaction is being performed e.g Funds transfer, a transaction charge is deducted and updates the system account's earnings/balance by querying the current balance and adding up the deducted charge and then finally updating the balance field.
Now my problem is that when multiple transactions maybe 200 of them are simultaneously executing by different users with different accounts, there is a discrepancy between the total earnings balance that I expected from what is being actually registered in the system. I believe it has something to do with having to asynchronous nature of server-request or something, how can I prevent this??
There is transaction in codeigniter. you can refer Codeigniter Transaction
you can use as
$this->db->trans_start();
YOUR QUERY / QUERYS
$this->db->trans_complete();
I am new to PHP. I am creating a system which shows customers, subscription package, and balance amount.
I have created user CRUD system and Packages CRUD System. What I want to have is to increase balance amount every 30 days, basically like recurring subscription. What I need is basic guideline.
This works like this -
Created a customer
Assigned him a Package
Balance amount increases every 30 days
(I'm Stuck on 3rd Point)
Well, the basic approach would be to:
Do NOT keep track of a "balance", but register the "end date" of the subscription. You can both keep track of the last month paid as the end date of the contract. Actually you can register more dates and make this as complicated as you want.
The "basic guideline" is that in the database you store dates and not balances. This allows you to only make changes as part of a transaction (like paying changing/adding a contract).
Hope this different approach helps you.
So I am dealing with Authorize.net's ARB, and I have a situation where the user is applying for usage of our service for eg. 3 months. We charge the user for this period - 3 months, but we don't make a subscription immediately. The thing is, we don't want to automatically charge them again once the membership expires after 3 months, but only if they go to account settings and set that option (extend membership automatically). So if they don't select it, there is no need to establish a subscription, so that's why we aren't doing it in starting point, once the user applies for this service.
So the question is, should I create a new subscription once user selects "Yes" for that option, and delete the subscription when he selects "No" ?
Is there another way to do it?
It's really hard to find some answers by Google, and I was hoping someone with more experience will have an answer here.
Thanks in advance.
When the user selects "Yes" for the new subscription just create a new ARB subscription with a start date of three months past their three month trial period. The three month subscription will run its normal course and terminate after three months. Then the new subscription will start at that point.
But here's the catch with that solution: you need the customer's credit card information in order to recreate another subscription. Unless you store it somewhere (bad idea) you can do that. So you would need to ask for it again. That's a large hurdle to overcome and will negatively affect conversion rates.
Alternatively you can automatically create the three month subscription at the point where the user starts their three month trial. As they approach the end of the three month trial you should make them aware there subscription will automatically start unless they cancel it. This solves the creation of the subscription problem but isn't very popular with users as nobody likes being automatically enrolled in a subscription.
Third option is to use Authorize.Net's CIM API to create a payment account for that user. Then you can charge against their card whenever you want. The problem with that is CIM does not support subscriptions. So you'd have to write your own subscription engine to make this work.
So there is no ideal solution for this. You just need to pick the one that you think works best for you.
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.
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.