February 1, 2010 at 8:17 am
I would like to hear how you are handling ePayments and database transactions. Specifically when the payment vendor is being called. Here are some questions which come to mind:
1. Is the payment process detached from the database updates?
2. Are all transactions being written to the database first, then the payment vendor is called to process the total amount from the transaction? In this case, what happens when the payment fails?
3. Is the payment process part of the database transaction.
4. Do you process the money first, then do the database transactions? In this case, if the db transaction fails you then have to issue a credit.
Are there any recommendations for handling payments and database transactions?
Let me add that a shopping cart is involved, so several items may be paid for at once.
thanks
February 1, 2010 at 9:30 am
I've done this two ways. Note that this was relatively low volume, but it worked in each case.
1. We process the order and load into the DB. Meaning everything is stored in our database, but the order is "pending." The application then sends a note for payment processing and receives success/failure.
2. The application keeps all session in memory, calls the payment processor, notes a positive result and then stores in the dB.
I prefer #1 because if the payment fails, or the web server explodes or something else, we have the order still marked in the database. The user has a chance to resubmit without redoing their order. Note that inventory becomes an issue. You don't want to deduct from it until payment is received, but you also don't want to be "out of stock" once the payment processes. Typically what I believe happens is that you time stamp the order and inventory is deducted for xx minutes. If that time passes (need a process to check this), the order is suspended or removed and the inventory is put back.
February 1, 2010 at 9:37 am
Thanks, Steve.
#1 seems reasonable. If one of the cart items fails to process, you then wouldn't submit this as part of the payment which would eliminate a "credit" issue.
February 1, 2010 at 9:40 am
Be sure you walk through all failure scenarios and then make sure you have enough flags in your order details to handle the possible places where you need to keep the status of each item. Especially if you have multiple payment processors.
November 11, 2024 at 11:33 am
This was removed by the editor as SPAM
November 11, 2024 at 11:35 am
I would like to hear how you are handling ePayments and database transactions. Specifically when the payment vendor is being called. Here are some questions which come to mind: 1. Is the payment process detached from the database updates? 2. Are all transactions being written to the database first, then the payment vendor is called to process the total amount from the transaction? In this case, what happens when the payment fails? 3. Is the payment process part of the database transaction. 4. Do you process the money first, then do the database transactions? In this case, if the db transaction fails you then have to issue a credit. Are there any recommendations for handling payments and database transactions? Let me add that a shopping cart is involved, so several items may be paid for at once. thanks
To ensure a smooth ePayment process with database transactions, here’s an approach that addresses each point in your question:
Detached Payment Process: Many implementations separate the payment process from database updates to ensure atomicity and reduce the chances of inconsistencies. In this case, the system can first reserve or log transaction details, then confirm the payment and finalize the database update only upon successful payment.
Database Write Before Payment: Logging the transaction in the database before calling the payment vendor is beneficial, as it creates an audit trail. However, if the payment fails, you’ll need a cleanup or rollback mechanism to maintain data integrity. Using a two-step process—logging and confirming—ensures there’s a record even if the payment doesn’t go through.
Integrated Payment Process: Some systems embed payment processing within a database transaction, creating a tighter coupling. While this ensures consistency, it can slow down the transaction, especially if the payment service takes time.
Payment First, Database Second: Processing payments before writing to the database can help ensure funds are available, but it introduces complexity if the database update fails, requiring a credit or refund. For security and ease of handling such issues, using a virtual card like Linkpay.io is advantageous as it enables precise control over each transaction, offering added flexibility in cases where refunds or adjustments are necessary.
For a shopping cart scenario, ensuring transaction reliability across multiple items is essential. One effective method is using a transaction log or state management system that confirms each step—item selection, payment, database update—to handle any failures gracefully and keep data synchronized.
Using linkpay.io virtual cards, you gain added security and control over individual payments, helping to streamline this process while maintaining a clear record of each transaction.
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply