I have seen the following can be done with Paypal. But is it posseble to make it happen using iDeal?
This is what I want:
Customer buys product for $20 in the webshop
$8 of the $20 must be deposited at the bankaccount of administrator 1
$12 of the $20 must be deposited at the bankaccount of administrator 2
Of course I can say to one of the administrators to transfer the rest of money to the other. But since we are talking about thousands of customers and transactions this is not the most practical solution.
Can it be done with iDeal? Of are there any alternatives?
Related
I am trying to figure out how to handle consistency in the database.
In scenario:
User A has an accounting document in the database include a balance field representing the amount of his current money. (supposed initially he has 100$)
My system has many methods to charge his account.
Suppose 2 methods occur at the same time, each method charges him for 10$, these steps occur concurrently in below orders:
Method 1 READ his balance and store in memory (100$)
Method 2 READ his balance and store in memory (100$)
... some business logics
Method 1 UPDATE his balance by subtracting variable in memory by 10 (100$ - 10$) and then save it
Method 2 UPDATE his balance by subtracting variable in memory by 10 (100$ - 10$) and then save it
This means he has been charged only 10$ instead of 20$.
I searched this situation a while and can not get it clear (sorry for my stupidity).
Really appreciate yours helps to enlighten my featherbrained. :)
You just discovered why financial transactions are complicated :-)
Have you ever wondered why it takes time for you to have an updated balance in your bank account? Or why you actually have two balances, instead of one?
That's because your account can actually go negative and (up to a certain point) that will be fine.
So in a real life scenario what happens is that you have a balance of 100$, you pay 10$ and until that transaction is processed and confirmed by the receiver, you still have your 100$. If you do 20 transactions of 10$ each, you'll be able to complete them because the system will most likely not be able to notice.
And honestly, it shouldn't. Think of credit cards, you might not have enough money now, but maybe you know you'll have enough when the credit is due.
So, the race condition you describe only works if you actually read the value and then update it.
There are a few approaches:
Read the current balance, and update the row using the old balance as a field in the where statement. This way if it updates no rows you know that you need to re-read and update.
Don't update the balance and only do it time-based, say once per hour. Yes, you might still have to do some checks, but the system will overall be more responsive.
Lock the database row as your first step. This would work but there's a chance that it will make the app slower.
Race condition you describe is low level design concern. With backend engine like Node that will handle the incomming request in first come first serve fashion you don't need to think about this case. Race condition you describe is not possible if you respect the order in which database update callbacks are fired. They are fired in the same order they have been issued in. So you should call next update only when the previous has finished. Promisses are great way to do this.
My employer has challenged me to build him a custom Point of Sale system and stripe was my first thought for payment processing. I work in food-delivery, and as such our current (as well as every other) POS immediately charges the card (verifies it? whatever), and then at the end of the night when tips are counted (whether from the drivers or tipped receipts in the tip box) the charge changes to whatever the customer agreed to.
I see I can do a few similar things:
update metadata on a charge (not what I need)
capture a charge (not what I need - won't let you use a value higher than the initial)
do a second charge for the tip (would hope to avoid this)
save the card information with Stripe after creating a customer object and not do any charge until after I know the tip (would hope to avoid this)
But, can I verify the customer can pay the amount (that initial charge) and then increase it later once we know if/how much they tipped?
Simply put, I'd like my flow to be:
Customer orders
Charge is issued for 20$ of food (Stripe)
Food is delivered, 5$ tip secured on the receipt
Receipts are turned in, 5$ tip is entered into system
Charge is changed to reflect the added tip (now 25$) (Stripe)
Is this possible with Stripe? If so, how?
If not, do you know of any other payment system that could implement this flow?
Short answer: no, that's not possible.
You could do something like this:
Create an uncaptured charge for the base amount.
Once the customer confirms the tip, try to create a charge for the base amount + tip.
3a. If the charge succeeds, release the first uncaptured charge (by refunding it).
3b. If the charge fails, capture the first uncaptured charge (and maybe explain to your customer that they were only billed for the base amount).
I have a question regarding my Firebase setup, with respect to security and practicality.
The goal is the enable a user to purchase credits, and spend those credits one by one. To enable this, I set up a "users" object where I store user-data (name, address etc.), a "transactions" object where I store all the purchases (amount, time etc.), and a "spendcredits" object where I store the data connected to the user spending a credit (time, on what, etc.).
Since the App must know how many credits the user can still spend, I created a variable in the user-object called validCredits, where the current available credits should be stored.
The user has read+write rights to his own user-object within "users" and read+write rights to his own object within "spendcredits". Only a different server has read+write rights to the "transactions" object.
So what happens is, the user purchases 5 credits. The server updates his validCredits variable with +5. The user spends a credit (-1), spends another (-1) and purchases 5 more credits (+5). His new validCredits amount is then 8.
I'm not sure whether this is a safe/optimal setup. I'm afraid that since a user has write rights to his own account, where the "validCredits" variable is stored, it might somehow be possible for him to add extra credits by increasing this value? Or can that be prevented by only allowing the user a "-1 credit" operator on this field?
I can also imagine that you might want to store everything in the "transactions" object, and just do a sum of all transactins when the App request the latest number of valid Credits? What is generally recommended for such a system with payments and credits?
The following rule can be used to enforce that a user can only decrease their validCredits by one at a time. I'm assuming that you have some way of distinguishing the server from a user, which is what auth.isServer represents.
{
"users": {
"$uid": {
validCredits": "auth.isServer || newData.val() === data.val() - 1"
}
}
}
we do allow him to call based on his current balance, the call is scheduled for 10 min, next call comes in it is also scheduled for 10 min because the customer balance was not updated as his first call is still in process. we only update the balance when a call is disconnected. in this way balance will go negative. but is there is any solution to this problem so that balance do not go negative ?
Banks solves this problem by placing a "hold" on the funds, and tracking two separate balances: the current balance (all money in the account) and the available balance (which is the current balance, minus the total of all the "holds" on all funds outstanding).
Let's say you have a balance of $10, and the calls cost $1/minute.
The idea is that your first 10 minute call wouldn't actually deduct the funds before it was done, but it would say, "Hey, I'm going to need $10 out of the current balance." The money, as you said, is only actually taken away when the call is disconnected.
However, because the "hold" on that $10 is already in place, when the second call is setup, it checks the balance and says, "Hey I'm going to need $10," but the algorithm would take the total balance ($10) and subtract the total of all the "hold" amounts ($10), and return $0.
So, basically the second call wouldn't get setup, because you balance algorithm would say, "Yes you've got $10 in your account, but you've currently reserved $10 of that, leaving you with $0 'available balance'. Therefore, I can't reserve the time for your call unless you either cancel your first call, or add more money to your balance."
I need to know is it possible to reserve or lock money with First Data API. Actually I don't know if process I am looking for is actually called "reservation", but I am thinking of standard procedure of locking certain amount of money on client CC so that client cannot spend it but I as a merchant, can return money without any cost to bank, client and myself if client or merchant wishes so. Kinda sorta like deposit. I just don't want to do full transaction and then return money with full transaction and pay every single step of it and then some for accounting nightmare.
1) Do an Authorization (a.k.a. Auth Only, Authorization hold) to freeze the maximum amount of funds you wish to access at a later date. Record the approval code from this transaction.
2) When it is time to charge the funds you wish to receive from the customer perform a Capture using the approval code received from the Authorization in step one.
Caveats:
1) You have a maximum of 30 days to capture the funds. This number may be lower for some credit cards.
2) You may only capture the funds set aside or less. You cannot capture more then the amount authorized.
3) You can only capture the funds once. This means if you capture an amount less then the total amount authorized and then you wish to go back later and get more you cannot do so. You would need to process another transaction with a fresh approval number to do so.
An Authorization hold may be what you need.