Storing credit card details...

[njdubois]

Is not an option.

 

There, now that I have your attention, I have an interesting problem.

 

We are a portal for non profits.  We have no leverage over what payment gateway a non profit uses.  We need to token-ize credit card details, regardless of the gateway.  Whether a gateway supports this process , even without first having a successful transaction seems to be a flip of the coin.

 

For example, paypal pro and stripe will return a token during the checkout process, but you have to go through that process, with a dollar amount.  Authorize.net and transnational allow you to "vault" the credit card details.

 

Paypal pro will let you capture details, and change the capture amount, but is limited on how much that amount can change.

 

Our current project is a auction app, and we need to insure that someone can't skip out on a won auction.  So we would like to get credit card details, and store them at account creation.

 

It seems the only option is to store these details ourselves, but of course this leads to HUGE complications, risks and will require a substantial cost in time on a regular basis for the entire lifespan of this project.  Continuously insuring compliance, and keeping up with changes to be secure would almost be a weekly task.

 

So what do we do?  If we can't/shouldn't store the credit details, and we can't get a non-profit to use a payment gateway of our choice, what are our options?

 

We cannot be a middle man for the payments as it goes against a message.  

 

Thoughts, recommendations?  Ropes to hang myself with as this seems like it's a lose lose situation?

 

lol, thanks!

[requinix]

we need to insure that someone can't skip out on a won auction.

Do you? I mean is there a real reason why you can't penalize a non-paying user for skipping out? Is there some reason why a finished auction cannot be restarted due to lack of payment? You could always, say, have the second-highest bidder inherit the winnings if the highest doesn't pay up.

 

 

Anyway, you do have some leverage, whether you like it or not: the technical and business requirements of your application. Whatever gateway must have a way of performing the actions you need - the clients can choose whichever service they want but it must somehow support certain features.

 

Storing details is out of the question. Don't do it. It's a huge hassle, not to mention a big responsibility with legal ramifications for failure.

 

The problem you're trying to solve is that you can auth for an amount but if the bids get too high then you're stuck. I can think of a couple possible business-rule solutions to that:

1. Auth for the initial amount, possibly a bit more, and have the user re-auth if the bidding goes over the limit imposed by the gateway. Or a fixed amount. Whatever.

2. Implement auto-bidding: user puts down the highest amount they're willing to bid and you auth for that much. Then auto-bidding rules kick in. If the user loses out then they can re-auth for a higher amount.

3. Act as a sort of gateway yourself. Use whatever actual payment gateway(s) you want, you take all the money directly, then you automatically/periodically transfer funds to the clients. You have full control over everything.

[njdubois]

Thanks a million for the reply!  To answer your question, what we figure would cause someone to not pay for a winning bid is when they literally wanted to slow the non-prof down.  Giving the item to the next highest bid isn't a punishment for them as they don't care.

 

As for your other options, they are fantastic.  From a programmers perspective they seem like the way to go, but for the UX perspective maybe not so much.  Is a customer going to enter their credit details a second time to increase a max bid 10 bucks?  Maybe, maybe not?

 

Our major takeaway from your reply is that awarding the next highest bidder is the smart choice, regardless.  We are going to take payment details at the time the auction is won, and if they don't pay, give it to the next in line.

 

Really you gave us peace of mind knowing there isn't some key bit of software out there already, and maybe there should be?  I guess our competition actually did become their own gateway, which means they did the work to be able to store CC details.  Which must be insane.  The basic reading I did on it scared the crap out of me.

 

Thanks again for the reply.  You have been a huge help steering us towards the best solution.

[requinix]

Giving the item to the next highest bid isn't a punishment for them as they don't care.

The punishment isn't them missing out on the auction. It's whatever you decide to do to them. Like, three strikes and they're out.

 

As for your other options, they are fantastic.  From a programmers perspective they seem like the way to go, but for the UX perspective maybe not so much.  Is a customer going to enter their credit details a second time to increase a max bid 10 bucks?  Maybe, maybe not?

That's a gateway question. I'm pretty sure most of the big vendors, if not all of them, support something resembling payment profiles: you hand them the billing details (or send the user to the site to enter it themselves) and you get an identifier back that you can use for automatically processing future payments.

 

It swaps the credit card management UI for a billing method management UI. From personal experience I'll tell you that they both take about the same amount of effort to design and implement.

 

Our major takeaway from your reply is that awarding the next highest bidder is the smart choice, regardless.

That way the auction doesn't go to waste

 

We are going to take payment details at the time the auction is won,

Also consider offering a window for payment. Perhaps the bidding went unexpectedly high and the user needs a couple days to authorize the payment against some authority (which obviously comes with the risk that they say no, followed by your penalty for reneging). Or maybe the user wants to wait until payday. Not talking a very long period here - a couple days, or even up to a week if you're feeling generous. Also depends on the nature of what's being sold.

 

Really you gave us peace of mind knowing there isn't some key bit of software out there already, and maybe there should be?

There is stuff out there that deals with this subject, but the requirements vary enough that there isn't just one single solution. Software you make for yourselves will always be better than something generic you can find or buy made by people who don't know your business. (given the same level of programming talent, of course)

 

I guess our competition actually did become their own gateway, which means they did the work to be able to store CC details.  Which must be insane.  The basic reading I did on it scared the crap out of me.

If you didn't think PCI compliance was scary then that would be a warning sign to me. Offloading all that to trusted third-party services lets you worry less about the details (you're still responsible for some of them, of course) but in exchange means that sometimes your business and/or software sometimes needs to reconsider how it's going to do what it wants to do. But the industry has grown much over the last couple decades and it's not nearly as hard or awkward as it used to be.

 

As an example, last I knew Authorize.net does not allow you to see an entire credit card number stored with a profile, so if you had a business requirement that the user could see the whole number then you're out of luck. Of course with this particular example not knowing the full number is actually a good thing; what you can get is the first or last few digits, which is really all you need anyways.