Unique item or booking plus payment gateway

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

I know how I do this (well I guess I would wouldn't I :-), but I was
wondering if there was a common (maybe better) pattern for it. I
haven't figured out a good search to find discussions on it.

A shop application with single unique items (e.g. artworks) or a
booking system for say, holiday cottages, theatre seats or limited
places course enrolments.

Someone clicks to buy one of these and then gets sent off to a payment
gateway site. At some point in the process, the partial purchase must
be "locked" to the user, so that it is not possible to sell the same
item to more than one user.

However, there is no guarantee that the user will complete the sale at
the gateway, so at some point the partial purchase must be
"unlocked" (if the sale is not completed)

I have seen a theatre booking site where the seats you wish to buy end
up locked (to you) but also unable to you because the sessions are not
handled perfectly. They tend to become available some time later.

The method I tend to use is to lock the potential purchase with a
session identifier and a time and to unlock it if the sale isn't
completed within an arbitrary period of time (e.g. 30 minutes).
Provided that the gateway supplies such a function, I will make a call
to it to check if the unique transaction ID I created for the sale has
actually completed but it was not communicated back to me.

My gut feel says that this is not perfect and there is still a
possibility that I could end up selling the same unique item to 2

Plus there is the opposite scenario where a sale could be missed
because the item is unavailable for sale even though the original
transaction has been abandoned.

One's first thought is that if "feels" like a simple transactional
model, but the fact that the user may go away (indeed always does go
away to the gateway site), means that transactions do not really fit
teh bill.

So how do others manage this and/or can someone suggest a search or
other reference discussing this scenario?

Re: Unique item or booking plus payment gateway

Captain Paralytic wrote:
Quoted text here. Click to load it

Hi, Paul,

Since you're sending them off-site to complete the payment, there isn't
a good solution.  As you said, you don't know if they've completed the
transaction or not.  And even waiting 30 minutes (or whatever) and
releasing the item is not a sure-fire thing; I've seen Paypal's IPN take
2-3 hours to respond after they had an outage and had to catch up.

Larger sites, like Major League Baseball use their own payment system
and give you a short time (i.e. 2-3 minutes) to complete a page.  If you
don't complete the page in time, the tickets are released and you are
notified you have to start over.  Once your payment information is
accepted, they permanently delete the seats from those available.

Depending on who you use, this may or may not be realistic.  Many credit
card companies have API's a developer can use to process credit cards;
of course, this means the site owner will have access to the credit card
  information; this may or may not be a problem perception-wise, and
they have to take more precautions with the security of their server.  I
wouldn't do it on shared hosting, for instance.  But it is one way.

But for those who can't do their own credit card processing, there's no
"perfect" answer, as you have found.  IMHO, you're doing it the best way
you can.  Yes, you may miss some sales; but would you miss many?  And
which would be worse - missing a sale or selling the same item more than
once?  Not that either answer is ideal, but it's a choice you have to make.

Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.

Re: Unique item or booking plus payment gateway

Quoted text here. Click to load it

Isn't there more to it than that?  A customer buys *one* seat at a
time?  Customers for theater seats tend to want several seats
together, or in the case of large groups, several sets of groups
of seats together.  If they can't get all the seats they want, maybe
they don't want any of them.

The point here is that there's a period between selecting seat(s)
and going to checkout.  Customers want to be able to lock seats
during that time.  They might wander off if, for example, they can't
find 13 seats together.  The lock time *while browsing* might not
be the same as the lock time *while checking out*.  A shopping cart
display should give warnings about items with expired or near-expired
locks, or just extend the time a bit.  If the customer keeps looking
at the shopping cart, he's still around and hasn't abandoned the
session.  When a customer goes to checkout, your code might want to:

(1) check that the customer still has locks on all the seats he
wants to buy.  If not, try to renew them.  If that's not possible,
inform the customer and don't send him to the payment processor.
Hopefully this should rarely happen.

(2) Extend the time limit on locks when going to checkout to give
the customer a minimal time to complete payment.

Also, you might want code that allows a customer to remove seats from
his shopping cart (he immediately reserved 5 together; now he
found 5 better seats and wants to release the first 5 before

Quoted text here. Click to load it

A fixed timeout might be less desirable than shorter timeouts that
keep renewing.  If the guy looks at his shopping cart, or one of
the pages with seats on it, you could reset the timer.  If he really
goes away to another site, or his computer crashes, locks get
released faster.  But some guy spending a long time browsing will
have the time he wants.  From the interface, you're probably still
stuck with one timeout between getting sent to the payment processor
and completing the payment.

Quoted text here. Click to load it

You could lock a seat to a customer, not a session.  However, this
requires customers to create accounts, and it may involve a lot of
confusion should two people sharing an account try to use it at the
same time (consider a corporate account where several executive
secretaries might use it for different events.  Or consider a husband
and wife who don't coordinate well).  This approach probably makes
more problems than it solves.

Quoted text here. Click to load it

How is not having this acceptable for a payment gateway?  Leaving
aside the unique nature of your product, this is a problem.  You
may or may not have sold something but you don't know whether to

If the payment gateway generates its own transaction IDs when you
forward the browser, you can tie those to YOUR transaction IDs.  At
some point, the payment gateway needs to inform you (or let you
check) that a purchase completed, and this should work reliably
even if your site goes down, the payment processor goes down, or
the payment processor gets badly backlogged so response time is a
lot worse than expected.

Quoted text here. Click to load it

Nothing is perfect.  There's also always going to be someone who
starts to buy tickets, gets confused, then completes the purchase
2 weeks after the date the tickets are for.  The objective is to
minimize the number of times this happens.  Some of this is going
to fall on Customer Service, as will the cases where payments are
made with stolen credit cards (or credit-card number generators)
and the payment processor doesn't immediately detect it.

You should know when this happens.  The payment gateway will indicate
completion of two orders which, according to your database, have
the same seat on the same day/time.  You should detect this and try to
do something about it, like figuring out who paid first and sending
the others an apology, and offering to cancel or modify their orders.
A phone call from customer service would be appropriate.  Have a policy
laid out for this.

Quoted text here. Click to load it

That should only happen if your seats are nearly sold out, and
that's a nice position to be in.  Some of this is unavoidable.

This might be minimized by user interface.  Display the seats with
a color code (for color-blind users, also use a different icon):
    Green - available & not locked
    Yellow - locked by some other customer.
    Blue - locked by this customer (whether paid for or not).
    Red - sold & confirmed paid for.
and carefully explain what it means.  Customers seeing few green seats,
and not in places they want, might keep coming back to see if the yellow
seats turn back to green.

You might have to be careful about this as some idiot might decide it's
a challenge to turn the whole seating chart yellow without buying any

Quoted text here. Click to load it

A feature of the payment gateway allowing you to specify that this
offer is only good until <time> might help this (use your half-hour
time limit or whatever).  The gateway will (hopefully) refuse the
transaction after that time.  I don't know whether any gateway has
this option or not.

Quoted text here. Click to load it

Re: Unique item or booking plus payment gateway

Gordon Burditt wrote:
Quoted text here. Click to load it

Not normally, Gordon.  The customer specifies the number of seats he/she
wants, and the system attempts to find all of them together.  If it can,
it presents them as one package.  If not, it tells the customer who then
has the option of getting smaller lots.  Large groups are generally
handled via telephone, not the web site.

If he wants to look for other seats, he needs to first release the
current ones, then look for something else.

Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.

Re: Unique item or booking plus payment gateway

On 2 Aug, 23:33, gordonb.xb...@burditt.org (Gordon Burditt) wrote:
Quoted text here. Click to load it

Hi Gorgon,
I really do appreciate the time that you have spent supplying all
these answers.

Unfortunately you have missed a couple of important points from my
original post and thus most of what you have written is not relevant.

I offered a list of the types of sales scenario where this problem was
prevalent. Theatre ticket booking was but one of them. I did indeed
state that for the theatre scenario the item in question was "seats"
rather than "seat". you however have gone to great length talking
about buying theatre seats when this is not the issue.

You also mentioned about extending timeouts whenever a user interacts
with the site. This too is completely irrelevant to the issue.

I have no problem with any of this whilst the user is at "my" (or the
client's) site. The whole issue is where a user is sent off to a
payment gateway site (Very near the top of my post I wrote "Someone
clicks to buy one of these and then gets sent off to a payment gateway
site."). At this stage, I know nothing about what is going on until I
(hopefully) hear from the gateway.

If I do hear from the gateway (the user has been returned to my site
by the gateway using a return url) then I can use something like curl
to do all the payment verification to ensure that the payment has
really gone through.

The whole point of my post was what happens if I don't hear back from
the gateway (say the user lost connection or their browser crashed or
they just went away or anything). Or maybe they are at the gateway but
everything is running slowly.

As I say, thank you once again for the time you obviously spent, but
it is unfortunate that none of what you wrote is relevant to the
question at hand.

Re: Unique item or booking plus payment gateway

We, the Senate of Arcturus, take note that Captain Paralytic said:

Quoted text here. Click to load it

Essentially you have two scenarios. In one the user got to (for example)
PayPal, and decided he couldn't afford the seats after all, shut down his
computer and went out for a beer. In this case nothing came back.

In the second case the user paid, but PayPal failed to deliver the IPN.
You have the advantage here that PayPal will continue to retry at a
diminishing rate until it finally gives up after several days.

What I did with the bookshop was to create a table to transaction records.
When a user checks out a TR is created with state NEW. When the IPN
delivers, and this is done asynchronously, the customer does not have to
be logged on, the state changes to CONFIRM and the books are delivered.

Now if PayPal took the payment then at some time in the future delivery
will happen.

Your case is more difficult. I can sell two copies of the same book to two
people. You can't sell the same seat twice.

I think the best way to proceed would be to put up a message saying that
seats will only be held if payment is received within (say) one hour. If
you create TRs like mine you can take the NEW TR as holding the seats, but
before testing run an update that changes any NEW TR more than an hour old
to status FAILED.

If a payment subsequently comes in for a FAILED record you may have to
contact the customer and explain.

Site Timeline