Test REAL credit card #'s and CVV with authorize.net - authorize.net

My client would like to test his application using real credit card #'s and real cvv codes. We don't want to charge the cards, but we do want the system to act the way it would in production. Namely, it should validate both the CC # and CVV codes. Is there a way to do this with authorize.net? We are currently in "live mode" in the sandbox at https://sandbox.authorize.net.

No. There is no way to do this with real cards without actually processing them in a live environment. However, you can test your integration, including getting certain CVV responses, using a developer account. See this thread in their community forums for how to trigger certain results (i.e. declines, CVV mismatches, etc).

Related

How do I change a donation amount down the road?

I'm building a website to allow people to donate to a local charity quickly and easily. The charity allows direct donations, but it's primary function is to do "per mile" style donations, but with pull ups. In that past, they have collected the pledges ("I'll pay $1 per pull up"), then manual contacted people for payment after the event. This isn't very slick and very time consuming.
What I'd like to be able to do is collect a pledge and payment information, then charge people automatically after the event. From what I've seen, I should put a hold/authorization on their account, then capture it with the appropriate amount after the event. But reauthorizing will only allow up to 115% of the original, and I can't very well just authorize a large amount and let it sit for two months before reauthorizing and capturing it.
I know this can be done, but I haven't messed with this side of things before, and the REST API from paypal doesn't have an obvious solution. Is there something I'm missing? Should I be going about this a different way?
You can use reference transactions. I would recommend sticking with the Classic API for now, though. REST isn't as mature yet and doesn't have all the same functionality quite yet.
So in the classic API you would use Express Checkout and/or Payments Pro. You can process an original authorization and then simply void it, or use the card verification process with Payments Pro.
You won't need to capture an original amount, so you won't need to worry about the 115% cap on the capture.
Instead, you'll use the DoReferenceTransaction API to process any amount you need to at any time from that user's account account.
With Express Checkout you have to be sure to include a billing agreement in the setup. This guide outlines that whole process.
With Payments Pro you just do the original card verification / auth and then pass that auth ID into the DoReferenceTransaction API.
In either case, if you're working with PHP this PayPal PHP SDK will make all of the API calls very quick and easy for you.

Real Time Verification of credit card holder using autorize.net and asp.net(c#)

In my project I am using authorize.net AIM & CIM feature for payment processing, I want to implement real time verification of card holder during transaction using authorize.net & asp.net (C#) in order to provide higher level of security and avoid fraud transaction. I am doing R&D on this to have most prominent solution which will support for all types of credit card such Visa, Master Card,American Express, Discover etc.
Kindly provide help on this.
Thanks
From what I understand, you just want to verify if the card is valid or not, in other term you want to authorize a transaction.
For that Authorize.Net provides with API specifically known as Authorize Only
You can look into : http://developer.authorize.net/api/reference/index.html#payment-transactions-authorize-a-credit-card
It has the sample request XML as well as sample codes, have a look into it.

Working with my credit card company, daily charges API

I want to build an app that, for personal use and fun, that monitors my credit card transactions daily, and sends me a text based on the transaction.
Exactly what I am doing is not important, I'm asking how to get started to see if my credit card company has a service that would allow me to build an application that would get my daily transactions.
The application would monitor my transactions, via their service, and I would consume the info do what I need to do.
Any help in pushing me in the right direction to see if my credit card company has a service that I could use?

How do scripts communicate with banks?

What options exist to facilitate payments to banks or credit card companies? Are there programmatic APIs for banks that, say, perform the same actions as paypal might? I'm looking for libraries or options that aren't through an existing provider; that could be developed on their own.
Basically, lately I've become interested in ecommerce and I'm wondering how the communication between a website and a bank or credit card company is made.
I've looked around a bit, but I'm not really sure about the terminology in the field; any resources you could point me at, or good books about the subject would be awesome. Thanks!
You get a merchant account with a bank, then sign up with a merchant processor like Cybersource or Litle. The merchant processor provides an webservice API to process authorizations, payments, credits, and voids. You implement the processor's API and then you can do online payments. They act as a go-between for you and the credit card company. You're not likely going to get permission to communicate directly with the credit card's network.
Maybe use this link as a starting point. This is cybersource's API documentation.

recurring billing /w cvv2

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.