Ticketing Transactions in ATHENA
Gary Moore
0) Joe User finds tickets to buy
Example: Joe wants to see Jersey Boys on Friday night. He enters a quantity of "2" and the date and pushes search button.
Client: Requests tickets from athena
ATHENA: Responds to the client with the ids of two available tickets.
Client: Presents tickets to Joe User.
1) Joe User says "Yes! I want these tickets"
Client: Asks ATHENA to begin a transaction and lock these tickets
POST /transactions
Body: {"tickets":[ARRAY_OF_TICKET_IDS]}
ATHENA:
- For each included ticket, do the following:
o Check that SOLD=FALSE. If so, return an error
o Check the TRANSACTION_LOCK_EXPIRES property to see if any of these tickets are already involved in a transaction. If so, return an error (see below)
o Create a transaction_id (use UUID)
o Set the following on the ticket: TRANSACTION_ID, TRANSACTION_LOCK_EXPIRES to 180 seconds from now (somehow configurable), TRANSACTION_LOCKED_BY to some client application identifier (likely an API KEY) and TRANSACTION_LOCKED_IP to the IP of the client
- Return to the client a JSON response, including:
o An array of tickets involved in the transaction
o transaction_id
o lock_expires time
o status=OK
Client: Presents Payment interface to Joe User
2) Joe User enters Method of Payment (MOP)
Client: Asks ATHENA to extend the lock time so that Client can authorize and confirm the MOP
POST /transactions/{id}
Body: {"tickets":[ARRAY_OF_TICKET_IDS], "id":transaction_id, "status": "checkout"}
ATHENA:
- Resets the lock expiration on each ticket
- Return to the client a JSON response, including:
o An array of tickets involved in the transaction
o transaction_id
o lock_expires time
o status=OK
3) Joe User confirms his MOP and that he wants to purchase these tickets
Client: Initials payment processing. If success, notifies ATHENA to mark the ticket as sold.
POST /transactions/{id}
Body: {"tickets":[ARRAY_OF_TICKET_IDS], "id":transaction_id, "status": "complete"}
ATHENA:
- For each included ticket, do the following:
o Mark SOLD=TRUE
o Create an ORDER, add ORDER_NUMBER to tickets
o Create or update a PEOPLE record
- Return to the client a JSON response, including:
o An array of tickets involved in the transaction
o transaction_id
o status=OK
4) Client displays confirmation
-------------
This leaves us with the following endpoints for the transaction resource:
POST /transaction - Create a new transaction
POST /transaction/{id} - Update a current transaction
GET /transaction/{id} - Get details of a transaction
DELETE /transaction/{id} - End a transaction and release all locks. This is entirely optional.
Do we need HEAD?
Ryan Price
Seems pretty complete.
Is it really the client's job to handle the payment? That's a lot of
trust.
If that's true, it's kind of cool, because I as a developer might be
able to create a client that attaches itself to several Athena
servers. Locally we have a site called the Red Chair Project that
tries to aggregate tickets from several different organizations.
That's one instance of this I can think of.
I have to say I'm just a mailing list lurker. Glad to see the project
has reached this stage.
Peace,
Ryan Price
rpr...@ryanpricemedia.com
@liberatr
407-484-8528
DrupalEasy.com Training Oct 13-15 in Orlando
FloridaCreatives.com
Next Likemind: October 15th @ Drunken Monkey
Orlando Happy Hour: October 18th @ Crooked Bayou
> --
> Visit: http://athena.fracturedatlas.org/tix
>
> You received this email because you are subscribed to the "ATHENA
> Tix Developers" group on Google Groups.
>
> To post, email: athena-t...@googlegroups.com
> To unsubscribe, email: athena-tix-dev...@googlegroups.com
> For more, visit: http://groups.google.com/group/athena-tix-devel?hl=en
Gary Moore
Good point about the trust portion of Payments and it leads to how we're handling Client Applications interacting with ATHENA.
We're planning to provide a payment gateway as part of ATHENA. Clients can use this gateway to process payments, or they can use their own if they already have a relationship with someone. They can skip the payments all together if they do something like cash-only at the door.
The Transaction Helper doesn't care. Client tells /transactions that Client and Joe User are square and Transaction Helper goes about marking your ticket inventory to reflect that.
Your ticket aggregator is something that we absolutely want to support. Our goal is to make it easy for an Arts Org who uses ATHENA to make their tickets available to third-party sellers like Red Chair Project.
Thanks,
Gary