I have a functionality where I need to upgrade a plan for a subscription but only on the next billing cycle.
Default behaviour, when using swap() method, is that the prorate is calculated and then Cashier figures out how much to charge. In my case that is not a good scenario since i'm selling fixed amounts through another table and my quantity is always 1.
I've manage to find a partial solution and implement it like this:
$customer->subscription($current_subscription->name)->noProrate()->swap($plan->plan_id);
And it does not calculate prorate, which is fine, however it upgrades the plan immediately without charging the customer. I'm looking for either to delay this upgrade until the next billing cycle (have a webhook tell me when to switch plans, or to charge the customer right away, which probably isn't the best solution).
I couldn't find anything on Cashier docs i'm wandering is there a solution to this, or should I just go with manually implementing logic for canceling the plan and then staring a new one with the trial.
Related
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.
I am working on an integration for Braintree and trying to adapt the subscriptions to a model which can account for subscriptions which are "upgraded" from one plan to another. I can see that you can change the plan, and then separately update the price. However, this seems less correct than just cancelling a previous subscription and creating a new one.
So in summary, is there a native way to indicate upgrading a subscription or at least a best practice that most would follow for Braintree?
Full disclosure: I work for Braintree.
I would suggest changing the plan and then updating the price for your business model. Assuming upgrading plans includes an increase in price, you can easily prorate a subscription when the price changes in the middle of a billing cycle. In Ruby it would look like this:
result = Braintree::Subscription.update(
"subscription_id_to_update",
:price => "14.00",
:plan_id => "new_plan",
:options => { :prorate_charges => true },
)
One use case for canceling and then creating new subscriptions upon upgrade would be if the plan upgrade is on a different billing cycle, e.g. yearly instead of monthly, because you cannot update to a plan with a different billing cycle.
More information on updating subscriptions.
If you have any additional questions, feel free to reach out to Braintree support.
Having an emergency situation. Currently on my site I have some customers that are being charged multiple times for the same order. The payment gateway is Authorize.Net and the store front platform is Magento Enterprise. What could be causing this? Bad code, server error, etc? This has never happened before and totally random. If this isn’t enough info to help please let me know.
It's a coding issue but trying to spot the code will be difficult in a site like this. A developer will need to go through and review the entire checkout code to look for potential errors.
The best course of action is to look to see how far apart the transactions are. If they are very close together (i.e. a few minutes or less) you can try to fix this by setting the duplicate transaction window to a value large enough to block the duplicates from happening. In other words, if the duplicate transactions are happening within 60 seconds of each other, update the Authorize.Net code to set x_duplicate_window to a value of 180 (this value is seconds). That should prevent the duplicate orders from happening.
I have a requirement to be able to accept different forms of payment within the same order - ie not just the usual credit card or paypal for the whole thing, but perhaps paypal for one item, cheque for another. I know this sounds quite crazy, but there is a good business reason for the requirement so I can't just push back.
The best way I can think of implementing it at the moment is to have kind of a hub page, where you can "launch off" into multiple flows for each of the payments by opening new windows. I can't figure out a way of doing this in a linear flow as for example you can't guarantee that a user will come back from paypal, so you'd then lose the user completely.
Is there a neater way of doing this that anyone can think of, or can anyone point me to an example of a site that does somethign similar for inspiration?
Even when opening several windows at once, there is no guarantee that the user will complete all payment methods. So you are most probably going to lose a few users or payments. Be sure to send automated e-mail follow-ups for missing payments to minimize this problem. The e-mails could contain links to your payment providers for easy accesss to their outstanding payment operations.
This is a difficult problem, but how many payment processors do you have to go offsite for? Should only be paypal.
In any case, I'd give the user all their payment options on one page, and let them fill in the amount for each processor or payment type. Then the next page would list those they chose, the amount for each, and a link to "Complete this payment".
The link would open in a new window.
You'll have to have a good back end and javascript, as well as user warnings so that the payment page gets updated as each payment is processed. Consider using popup dialogs to show that a payment has completed, or that the order has sat idle for more than 10-30 minutes without complete payment.
Also, consider sending emails and letting the user complete the payments through links in the emails. Send a new email each time a payment is completed, and a final email if all payments are complete and the order is moving forward.
Send an email one hour, and one day later for uncompleted orders with remaining payments required, that also give them the option of choosing different payment options for the remainder.
Email isn't best (lose more orders that way due to changing minds) but it's good for the type of transactions you're thinking about.
Personally, I'd do it like this:
Let the user fill their basket in the ususal way
Allow them to add payment types and amounts to a list (2nd basket almost)
When the payments balance against the basket, start processing the payments
For external sites, try a frame which has a progress indicator at the top.
In an ideal world it wouldn't be linear. But a lot of users might lose a spawned window, or get confused by the parallelism.
Better to stick to established IxD principals and rely on good feedback instead. Give the user control from the outset and keep it transparent.
Lastly, start the payment process with the most immediate (e.g. paypal) to reduce users giving up. (COD should come last!)
Hope this helps,
Tom
If possible, just separate your order into separate smaller orders based off of the payment selections of the user.
And don't do it linearly. If anything you could open up each payment processor in a separate window so that you maintain presence.
I would take an approach where the whole order is broken down into sub-orders for each of the necessary payment methods. You can load the PayPal portion, the check portion, etc. and process them separately. It's important for the user to know how much is being charged to each of their payment methods, so it makes sense in this case to present the whole order as broken down by payment method (versus displaying as a unified order).
Implementation would be easiest if it's always a certain subset of items that is forced to any payment method. If this differs by user, or if it's when the order reaches a certain amount, the situation could become much more complicated. Can you be more specific about your approach?
Processing Multiple Order Payments
Give the user the option to make a payment for a pending order using any of your payment types.
Let the user specify an (Amount <= [Order Total] - [Payments Received]), if that is part of your requirement.
If the order is still pending after you process the payment (see how below), take them back to step 1 to rinse and repeat.
How to store and process each payment made:
Use a Payments table to store all order payments, the PaymentMethod used and its Amount with its CurrencyCode.
When a payment is received for an order, store the payment and sum all received amounts converted into your base currency as [Payments Received].
If [Payments Received] >= [Order Total], mark the order as Paid. Or, if dealing with double-converted foreign exchange rates, check if it is correct to within a small-enough margin, eg 0.5%.
Optionally, convert any overpayment into prepaid credit for the client.
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.