I'm integrating with Authorize.net's ARB API. Authorize.net processes their transactions at a certain time everyday, so when people create a subscription, their transaction is not real time.
I am creating a subscription based model, does their API tell me whether their CC has been processed? Or should I put a delay on the access to my site until they have processed all the ARB transactions that day.
Thanks in advance!
You should be charging their first subscription payment via the AIM API. This will give you instant feedback as to whether or not the payment was good. Assuming it was successful you then can use ARB to create their subscription by setting the start date to be the date of their next scheduled payment.
This serves two purposes:
If the card is bad you know immediately and can have the user provide a new card while they are still on your website. Once they leave your site it gets much more difficult to get them back to correct it.
You can give them instant access without worrying about whether or not their card is approved or not.
FYI, you can use Silent Post to determine the status of payments made via ARB.
Related
If a server is already listening to Real Time Developer Notifications what’s the benefit to also poll the Voided Purchases API?
The docs say:
Note: Unlike other order-related data sources, the Voided Purchases API includes purchases that are charged back by payment processors. Therefore, you might see inconsistencies between the information from this API and information from other order-related data sources.
This is too vague to draw any conclusions. Does that mean there are scenarios in which a subscription is invalidated which doesn’t trigger a RTDN and is only visible in the Voided Purchases API?
Google Developer Support clarified that the Voided Purchases API is only an addition for investigative / preventive purpose to counter refund fraud. For example, a user who subscribes and after a short time triggers a charge back, therefore having used an entitlement for free.
The API is not required to track subscription state, as a refund (like any other cause) triggers a RTDN.
You may use the Real Time Developer Notification (RTDN) to track any changes on the status of the user's subscription entitlement. Please note that the subscription is immediately revoked when the purchase has been charged back, you can refer to this link for your reference.
Additionally, you may still use the Voided Purchases API as part of your double security, and track the user's behavior to prevent refund abuse on your app.
I am developing an online ticketing system for events (like concerts). A basic part is a seat chart where the visitors will be presented the available seats/tickets to choose from. Once they make a selection, the system immediately tries to reserve the tickets for 10 minutes (by entering the ticket IDs into a table where ticket ID is key).
Only if the reservation was succesful, a paypal button is presented to make the payment.
All this works fine. Ticket Reservation is not a problem for me. I can handle that in my system. But once paypal comes into the game, things get difficult.
The Problem:
If the user for some reason spends a lot of time in Paypal (more than 10 minutes), the ticket reservation on my website will expire, allowing the tickets to be bought by another visitor, which might happen before visitor 1 makes the payment. Visitor 1 does not see any of this because he is still in paypal... At some point in time, he will manage to make the payment (e.g. after 15 minutes), which will perfectly work because paypal does not know anything about expired reservations.
In the end, I might have two visitors having paid for the same ticket/seat!
How can I prevent that from happening?
How do you handle race conditions if two systems are involved and one of them is out of your control?
My thinking was: Actually a check should be made right before the payment takes place, but of course I don't have control about what happens in paypal!
I know I can use Paypal's IPN and such, but this only happens AFTER payment which is too late.
Alternatively, it would be great if paypal asked me through API to confirm a payment. Then I could say "no" in case the tickets have been sold to someone else. But I don't think this is possible with paypal.
I'd recommend using Express Checkout. Express Checkout allows you to control when the payment happens, because you'll fire off an API call to PayPal to actually process the payment.
The other possibility you can look into is using an authorization instead of a sale transaction. That way, if another buyer takes the seat, you can void the authorization, and the buyer won't get charged. (PayPal will probably charge you for the voided authorization, however.)
One solution as Matt Cole suggested is to use 'authorization' instead of 'sale'.
You can do this by setting 'intent' to 'authorize' instead of 'sale' ({intent: "authorize"}) in your calls to the Paypal API when you're creating a Paypal payment. Once the customer approves the transaction, it is up to you to authorize this transaction by capturing the payment.
I have setup Authorize.net's Automated Recurring Billing in a system I have built, which works great.
The only downfall is when someone puts in bad billing information, AVS is not checked (and it returns successful). It only creates the account, and the payment will fail at the first time it is billed, which is often the next day.
How can I catch the bad billing information before we complete the transaction?
Use AIM to process the first payment. That way you know the card is valid before setting up the subscription and can perform AVS and CVV verification. If you don't want to charge the first payment, then do an AUTH_ONLY with AIM to accomplish the same effect.
I have been working on an application that needs to log credit card transactions which is dependent on using an external API. Within my application, I have the concept of an invoice with a total, and a transaction that when successful credit card payment is made, deducts from this total.
This is more of a platform independent question, but I am working with Django, Python and MySQL.
My question centers mainly around the use of transactions when dealing with external API's and how to design your software to handle potential failures. Both Django and MySQL support transactions, so that in itself is not an issue, but suppose the following scenario:
Credit card submitted though the payment API
Credit card is successfully processed
This response is then logged to the database as a payment on that invoice
There is an error saving the payment to the database for one reason or another
What do you do now?
If there was not an API call involved the answer would be clear, rollback the database transaction and raise an error. But having a call to an external API complicates matters, because this is not really a way to rollback on the external API call.
I am interested if anyone has run into this issue (for credit cards, or similar types of transactions) and how they addressed the problem, or in general some approaches for software design in this case.
It's hard to manage this in software. However, if your payment gateway is calling a callback to signify that the transaction is successful, it will presumably log an error if that callback fails to complete, and you should be able to configure it to alert you in that case, perhaps by email. Then it's up to you to rectify the situation manually.
I'm implementing a payment system and I'm not sure how to deal with cvv2 codes. Our service offers a two week free trial. We require the user to enter in billing information and we auth their card for $1. Two weeks later we do a separate auth & capture (we can't do a prior_auth_capture because the user can upgrade their plan during their trial). We bill them each month from then on.
How am I supposed to use the cvv2 code in our situation? We're not supposed to store the cvv2 code, so I can only use it with the auth that we initially do. Is it worthing doing this just on the auth still? I don't want the first auth to succeed (because it has the cvv2) and then prior auth + captures to fail because we don't keep it around.
Long story short I'm new at this company and I'm trying to fix their billing problems. International customers in particular are getting payments declined (some, not all). The current system doesn't pass along the name on the card to auth.net nor does it do any sort of address verification, which I suspect is what's giving international customers trouble.
I would think using cvv2 (if it'll work in our situation) and sending the actual name on the card should remedy the issue for international customers. If not then address verification would be the next thing to try? Does this make sense? Sorry if my thoughts are a bit scattered.
Thanks!
Sending the name on the card is useless as it not received nor used by the card processing companies. Also, AVS won't give anyone trouble except for the company who pays the credit card processing bills as their fees will be much higher for not doing it.
With Authorize.Net you should be using their ARB system for recurring payments. Once the subscription is established you don't have to do anything until the subscription runs out or is cancelled. This includes handling CVV and AVS issues. If you choose to use their AIM API for each and every payment then you'll have issues as you'll need to capture the CVV number for every transaction if you wish to perform CVV on those transactions. Of course, CVV is not required to process a transaction, so if you don't submit it the transaction will still go through anyway.
If international card holders are having issues it's more likely because the card is international and higher risk then then AVS or CVV issues. Those two tools are for fraud detection on your end. Not card approval by the processors.