I am Working in Authorize.Net, here I have to check the customer's credit card has sufficient amount before a transaction. Please help me.
Thanks in advance
Do a pre-authorization for the amount you need to charge. If it comes back approved the card has enough to cover the transaction. Just keep in mind that you'll be freezing those funds on that card so unless you release it immediately you will be causing harm to the user.
Pretty easy - set the transaction amount to the amount you need to clear.
Set the transaction-type to 'auth' - if you get an approval, they have the funds. Save the auth code in your database - you'll need it later when you capture the transaction to actually get the cash
Be sure to do a capture transaction later (like when you actually ship the order) to collect the cash on the auth you did earlier. You will need to furnish the transaction code and the auth code so they can map the capture back onto the earlier auth transaction and fund it for you.
Related
Let's assume there is an item.
It is sold by 100 users every second.
Describe one cycle transaction.
Amazon checks its stock. (10ms)
If an available request to card company for payment. (50ms)
Update item's stock. (50ms)
110ms(I decided arbitrarily) was consumed on one purchase.
How to handle this on amazon?
Is there one database on large services?
Is there a queue?
Just curiosity, Short answers or keywords are fine. thank you.
Currently I'm working web application that implement subscription plan service and there is 'digital wallet' which is user can deposit or withdraw, and so the wallet can be used pay the subscription plan as well.
My question is "to track wallet balance, is needed to store the balance into column at user table or I just track the transaction deposit - withdrawal - subscription payment?
I usually implement both options. I keep all transaction history, make sure it does not change (ever), and update balance at users table after each transaction is posted.
This way you have quick reads (you display balance without going through transaction history) and you still have all data in case something goes wrong.
Let's say we need to develop a bidding application such as one in eBay. We don't want one user's bidding to block another user's bidding, which will result in slow response. Also, when I place a bid based on the highest price I see, I don't want to arrive at the end with the app saying that sorry, the highest price was no longer the same; while I am placing the bid someone has pushed the price higher.
Which isolation level should we use? I was thinking of Read Uncommitted
for dirty read and no locking but not sure.
I would like to hear more real-world examples/use-cases for isolation level in SQL Server (or in general, any other database software, if there are similarities between them regarding isolation levels). For me I find it not very efficient just looking at definitions.
Thank you.
READ UNCOMMITTED sounds about right, in context of the scenario you envision... but that scenario sounds pretty bad!
when I place a bid based on the highest price I see, I don't want to arrive at the end with the app saying that sorry, the highest price was no longer the same; while I am placing the bid someone has pushed the price higher.
Maybe I'm misunderstanding, but do you mean if someone else bid while you were preparing your bid? If so, how else is it meant to work? Will you win, even though you bid lower, simply because the time of starting your bid was earlier? That won't work. This has to be decided at the time your bid is submitted.
Really, this should run with READ COMMITTED, so that the user's bid is affected by all the previous ones - at the point that is it submitted. That is a requirement for a sensible auction. Bids should run in temporal sequence, wrapped by TRANSACTIONs, and always be subject to the latest maximum at the time that their transaction began, i.e. when the user hit the Submit button, they should be subject to the sum of all bids submitted before theirs.
I am building a web application (in Django, though this isn't a Django-specific question). I will have a number of users and they will each have an account balance which will be incremented each time they deposit money with me (via PayPal) and decremented each time they use my application's API.
I am trying to decide which method would be more appropriate:
Store the balance along with the user as a single integer field. When money comes in, this field is added to. When it goes out, it is subtracted from. Simple, but prone to errors.
Generate the balance on the fly (with caching presumably) adding up all the payments and charges the user has made. A touch more complicated and slower however less prone to errors.
So, which is best or is there another way of doing it?
My opinion is that the first option is less prone to errors than the second. When you start relying on caching for that pretty important value you have to deal with cache synchronization. Obviously every time the users balance changes, you need to invalidate the cache and make sure that any read requests will be 100% accurate. If you do go the cache route, you just have to make sure that extra layer is very well coordinated.
What I suggest is that you store both a transaction history, and a balance total. The act of making a transaction needs to be atomic so that both the transaction history is made and the update of the balance total is executed, before anything else can read it. You then always have the option of reconciling the balance to the history, or reading and adding directly from the history.
Not happy with my transaction reserval database design
Scenario, User withdraw money from the system (application/game, platform etc etc) to his bank account.
The bank declines the bank transfer therefore the withdraw transaction failed. Now the system needs to return the funds back to the user minus a fee for the declined/failed transaction.
To perform the withdraw, there is 4 transactions entry (4 records created), then to perform the reversal of the transaction, there is another 6 transaction entry. In total 10 transaction entries! (10 records created!)
I feel that there may be a better way to do this! maybe could just flag the records as reserved, and add logic to the software for the reserved transaction???
Am i doing it right?
how do you reserve a transaction in a double entry accounting database design?
EDIT: reserving a transaction, is not
referring to a reseval of a database
transaction but rather the reserve of
funds.
I'm not sure this is a programming question. The issue here is the accounting requirements. In our system we would post a debit to the AR subsidiary ledger and then a credit/debit to the general ledger. If we then get a decline, bounced check, or whatever else, we post new transactions that reverse it. Without that there would be no record of what actually happened.
We do head off some of this with credit cards because we can settle those at post time. If a transaction fails to settle, the AR batch doesn't post and the clerk has to go fix it or delete the transaction. There's a posted flag on the AR sub-ledger transaction that must be flipped before it will impact the balance, and the GL is not adjusted until a successful post. If it does post successfully but then we get a chargeback, we still use the above method.
Really it comes down to what kind of records your comptroller wants to keep. They may want to keep track of the failed transactions for reporting and possible fraud detection. The general rule is once something is posted it should never changed.