Scenario : A user enters credit card information. System contacts the payment gateway , waits for authorization and sends confirmation to the user in case of success or failure !
This then implies that as soon as the user enters the credit card info, the system should give him a itinerray (temporary) confirmation subject to the authorization of course. The user can then go on his merry way.. does not have to block.
This suggests the use of an asynchronous processing model for the confirmation dosen't it ? Dosen't the fact that the system sends a confirmation mail even in the case of a failure imply a asynchronous model?
Any suggestion in this regard is highly appreciated.
.. that still dosen't the answer the question of needing an asynchronous model does it ? Seems like you are using a synchronous model. If you are going to block the seats straight away .. then the customer knows it straight away too.. what then is the need to send the customer a mail at a later time for confirmation ABOUT THE AUTHORIZATION ?
Of course you could send him a mail about the confirmed itinerary.. but in the secnario for example.. if the authorization fails.. what is the logical decision for the system to send the customer a mail that AUTHORIZATION failed unless the AUTHORIZATION (VERIFICATON) is deferred to a later stage ?
First of all, it is not "just" CC authorization, the CC company will authorize the CC and also debit the account when the CC is valid. This means that after you get the return from the CC company chances are high that the bill has been payed and that you must ensure that the cusomter gets his reserved seats on the flight. You cannot say to your customer: "well we debited your CC but in the mean time the flight is fully booked, sorry"
So, before sending the CC information to the CC company, you need to obatin a database lock on the table responsible for holding the reserved seats for a flight. After you have that lock, you may send the information to the CC company. When it returns with ok, you will increase the reserved seats in the database and release the lock. If it yields not ok, you just release the lock.
Fact is, if you make the system asynchronous you will not be able to put such as lock (well, you could, but you want those locks fine grained and as short as possible). If you do not put such a lock, how will you guarantee that the flight will not be fully booked when the CC compay answers ? Yes, you could reserve a seat before sending the payment information to the CC company (and cancel it if it answers not ok) but then you might endup with a flight that nevers gets fully booked...
I do agree that you could make the mailing notification system asynchronous...
Anyway, maybe you another vision ? But I do not see how a good CC system can be made asynchronous (and even if it could I don't see any benefits)
I agree with you that the credit card authorization system is synchronous. No questions there.
But there is nothing mentioned at all about the debiting.. that is in fact your assumption i.e you have made the assumption for that scenario. The requirement only is for authorization.
For example take Netflix - if you get a free trial membership for a month, you still have to supply the credit card number. Netflix will ensure your credi card is valid but will not debit your card right ? So INMHO these are two distinct operations
a) Authorize that your credit card is valid
b) Debit the card for the payment
If you assume a synchronous model for the payment, as you have assumed[ that the authorization goes with the debit], then I agree with your assessment. But in this case, how do you explain for the fact that if the authorization fails, the customer will ne notified by email seperately ? If the authorization fails.. he should get notified immediately isn't it - by virtue of being synchronous.
If you assume a asynchronous model [only for the aplications payment handling] for example, I would assume that when the credit card is supplied, the system talks to the gateway and verifies that the card is accurate and also whether the card limit caters to the amount specified. Shows the itinerary to the customer saying that this is temporary till the payment is made. At night or whenever, a batch job runs submitting the payment information. If the transaction succeds (debiting), the itinerary is confirmed, a mail sent and order to the ticketing system. If the transaction fails (debiting), the itinerary is saved , a mail is sent to the customer informing the customer that the transaction failed and maybe asking him to login withn 24 hours to supply an alternative payment form. If that dosen;t happen the seats are made available again.
This scenario accounts for the emails.
I can't see how the synchronous model will account for the emails .. unless the emails are just an after thought. I mean have you encountered a system (synchronous) that sends you an email for a failed transaction ? It would be handled online isn't it ? I would understand an email confirming your itinerary - not for a failed transaction. Any comments ?
I would like to know how asynshronous communication helps in sending mails. I guess we can send messages like queue and receive the response back. Do we need to use separate component for sending mails using messages received from asynchronous communication? please clarify.
Originally posted by Koen Serneels:
A credit card authorization system is per default synchronous.
So, before sending the CC information to the CC company, you need to obatin a database lock on the table responsible for holding the reserved seats for a flight.
i have a question about that "lock" you mentioned:
as i learned, it is possible to specify an isolation level for a database connection which is provided by the conection pool.
to have a lock on a table you have to set the connection's isolation level on "Serializable" or how do you assure that the table is locked?
Here is my thoughts...
Sending email to customer about the status/completion of transaction should be asynchronous based on Messae Queue model. Because
1. Throughput of the application should not get affected because of sending mails to customers.
2. Also mails sending should be fail-proof, ie if the system fails in the first time while trying to send the mail(say Mail server is down), it should attempt again, until the mail is delivered successfully.