When you sell a seat, that seat must be unavailable for the next ticket buyer. To do so, your ticketing system needs to call the /book  API endpoint (reference documentation here). We'll make sure the seats are firmly blocked for any other current or future ticket buyer. 

The question is: when is the right moment to perform that /book  API call, is that before or after the payment is processed? 

Or, put differently, do you opt for: 

  • the booking-first approach: first book the seat via the Seats API, and only then process payment, or
  • the payment-first approach: first process the payment, and only if that is successful, book the seat via the Seats API. 

We recommend the booking-first approach, even though that might seem counter-intuitive at first sight. In this article, we'll explain why.

Why is this important?

Technically, you cannot do both operations in one transaction. Both booking in Seats and processing payments require (at least) an API call that can fail for many reasons, both functional and technical.

The payment could fail because of a rejected credit card. Booking a seat in Seats can be unsuccessful because the seat was booked in the meantime by another ticket buyer or a box office user.
And of course, you should always program defensively, because any API call can always fail because, you know, the internet. 

In short: whichever operation you do first, both the booking and the payment processing can go wrong. And so, you need to think of a rollback strategy for the first operation, in case the second one doesn't complete.

Book in Seats first, then process payment

The payment-first approach may look like the logical thing to do: first start the payment processing, and only when we're sure to get the money, you make the seat unavailable for anyone else. 

However, there are important drawbacks to this approach. If the call to book the seats doesn't complete successfully, then your ticket buyer will have paid successfully for a seat they are unable to acquire in the end. That's not just a very bad ticket buyer experience, but you'll also have to provide a way for them to choose a different seat, or even worse: a refund. 

If, on the other hand, you first book in Seats, and only start processing the payment if that booking was successful, you won't have to deal with these issues. 

Instead, the only thing you need to do, is release the seat again in Seats if the payment didn't come through.

Conclusion

To avoid refunds and frustrated users, we advise you to follow these steps:

  1. book the seat via the Seats API
  2. if the seat was successfully booked, start payment processing. 
  3. if payment was processed successfully, you're done. Otherwise, release the seats again via the Seats API. 

Did this answer your question?