Credit Card Transaction Strategy

[mikekissman]

I've built an online reservation website in ASP .NET with a SQL Server
backend. It allows customers to search for available resources, than
charges their credit card a fee to hold the reservation. Here's how I
have it arranged now:

1. Find available resource
2. Store reservation info in database
3. Charge credit card

The problem is, if the credit card fails, I have to go back and delete
the reservation which isn't optimal. If I charge the card first, I run
the risk of charging the card, then the resource not being available if
two people are trying to reserve at the same time.

What I'm looking to do is something like make the reservation
transaction dependant on the credit card result, or any other advice on
a better way to do this. Any help would be appreciated!

[Cowboy \(Gregory A. Beamer\)]

On the simplest level, you can have a "flag" set to indicate whether the
card was authenticated. The resource is already checked. You then only
report on reservations where the flag is flipped from "no" to "yes". This is
not an optimal solution, but it improves on what you have now.

You can also opt for the "temporary" table to hold pending requests.

If you are completing the full trip, meaning checking resource and then
running card, within a short amount of time, you can hold the information on
the business layer until commit, putting a temporary hold on the resource
until the transaction rolls forward or back. This can work long term, but it
is harder to hold the transaction in the business objects for long, as you
are eating up expensive resources.

Service Broker Queueing (SQL Server 2005) may help, as you can work the
asynch processing into transactions, but you will be a pioneer in this
arena.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***********************************************
Think Outside the Box!
***********************************************
<mi*********@gmail.com> wrote in message
news:11**********************@g49g2000cwa.googlegr oups.com...

I've built an online reservation website in ASP .NET with a SQL Server
backend. It allows customers to search for available resources, than
charges their credit card a fee to hold the reservation. Here's how I
have it arranged now:

1. Find available resource
2. Store reservation info in database
3. Charge credit card

The problem is, if the credit card fails, I have to go back and delete
the reservation which isn't optimal. If I charge the card first, I run
the risk of charging the card, then the resource not being available if
two people are trying to reserve at the same time.

What I'm looking to do is something like make the reservation
transaction dependant on the credit card result, or any other advice on
a better way to do this. Any help would be appreciated!

[Phillip Ian]

Take a look at Delayed Capture on your credit card processor.

Basically, it allows you to "hold" a certain amount of money for a
given time. Doesn't charge the customer anything unless you later
"capture" the transaction.

So now you:

1. Find available resource
2. Do an "Authorize" transaction on the card to make sure they have the
money
3. Make the reservation
4. Capture the funds

If you fail to make the reservation in step 3, you simply don't capture
the funds. The customer isn't out any money, you don't have to credit
them, etc.

[mikekissman]

I'm using SQL Server 2000, so Service Broker Queueing is out. It does
look interesting though, thanks for the tip! I think I am just going
to move the credit card verfication inside the transaction and roll it
back if the CC fails. I can still see a possibility of two
reservations for a given resource being made at the same time, but the
window is small.

Thanks for the help!