I have a business scenario where Limit order per day is necessary.
For eg,
product schema:
productName,
limitPerDay=2,....
A owner can set limitPerDay for a product.
Users can either order the product or reserve the products(for 1 hour).
If the limit has been exceeded, users will be able to see LIMIT EXCEEDED label on product listings.
For ex. there are three users Adam, Bob and Tom . Adam reserves the product LAPTOP, Bob orders the product LAPTOP. Tom will not be able to reserve or order LAPTOP because the limit has been exceeded (TOM can see the product but will see the label LIMIT EXCEEDED and limit will open after 1 hours because Adam has reserved for 1 hour).
Scenario 1: One hour passes, Adam did not make purchase and his reservation is now over. TOM can see the availability and orders the product.
Scenario 2: Adam makes a purchase from it reserved list, now ADAM and BOB both have ordered. TOM will have to wait for next 24 hours to purchase the product.
How do I store these purchase and reservations to enable the logic which I would be needing. I am using MongoDb to store data
Most website doesn't reflect real-time changes. Usually user has to do refresh page,
In order to see recent changes.
Our database schema would be:
{
_id: <product_id>,
orders: [<user_id>],
order_count: number,
reserves: [reserved],
reserves_count: number,
}
reserved {
_id : <user_id>,
time: Data,
}
So when user request the product, then server need to do check up,
currentTime - product.reserves.reserver.time = if more then 1 hour then update reserves_count
limitedOrderRequest - product.order_count + product.reserves_count = 0; user has to wait 24h...
When updating document:
limitedOrderRequest - product.order_count = if 0 then user can't order
limitedreserveRequest - product.reserves_count = if 0 then user can't reserve.
Related
I'm using separate charges and transfers with Stripe Connect accounts.
So, if I create a transfer of $1.00 to a Connect account, Stripe is going to charge my platform(me) $2.00/month + % fees + $0.25/payout for that active account according to their Connect pricing page
Question - Is there any way to charge the Connect account or pass that $2.00/month active fee onto the Connect account, so my platform doesn't have to pay it? ex. Direct charge, negative balance, invoice, debit custom account, etc. Or is there a way to see the total pending balance that will be sent out to the Connect bank account and "take back" some of it before it gets delivered?
Concern and/or Challenge - When I issue a transfer, I won't have any problems recouping funds (my 5% fees, Stripe's Connect fees 0.25%) from my customers Connect accounts. I won't go into the math explicitly, unless you ask, but I will remove all fees from the transfer before it's sent, then check via "TransferGroup" to look and see if any transfers have been made to the Connect account for that pay period (1/month) and if no transfers have been created yet, I will deduct on another $0.25/payout to be withheld. BUT now I have to do something similar to collect/recoup the Stripe $2.00/month flat rate per active account and this is where my problem arrises. My transfers might all be for $1.00 each! Ex. $1.00x100. So I can't simply deduct $2.00 from a $1.00 transfer to collect this fee.
My idea - The transfers for Stripe are coming from a tipping mechanism I've implemented between students and instructors on my site/app. The students can tip $1,2,3,4,...N tips. I can do a check to see if any tips have been sent for the month and if it's the first tip, force a minimum tip amount of $3.00, for each additional tip a student wants to send, it will only be $1.00. So the first student to send a tip gets forced into a min. $3.00 tip.
Another idea - Check each transfer amount to see if it's >= $3.00, if true, I can take all fees including the $2.00 account fee and still be in the Net positive to transfer, but if this transfer group doesn't receive any $3.00+ transfers in a month, I would then track the amount owed/not collected ($2.00) and try and collect it next month. This might work but seems like a sub par solution. Maybe there's a better way?
Another idea - Allow the Connect account to go into a negative balance , if I had to take $2.00 + $0.25 + %fees out of the first $1.00 transfer. I don't know if this is a good idea or how it would work exactly.
Another idea - I was looking to see if Stripe has a way to look at the total pending balance that will be transferred out to the bank account before the end of the pay period and somehow deduct the $2.00 from the total? I see there is a way to debit accounts, but there are lots of restrictions so I don't think it will work for my scenario (lots of international accounts).
Another idea - Debit custom accounts seems reasonable but it has too many restrictions ex. doesn't work for international accounts.
Another idea - I was looking at Direct Charges where it looks like I can charge a Connect account, but looking at this code, it only creates a "Request". How does it get me the money? Is it automatically sent from the Connect account to me(platform)? What happens if I only transfer $1.00 to a Connect account for a payout, but then send a "Request" for $2.00, does the Connect account go into some negative balance?
var service = new PaymentIntentService();
var createOptions = new PaymentIntentCreateOptions
{
PaymentMethodTypes = new List<string>
{
"card",
},
Amount = 2000,
Currency = "usd",
};
var requestOptions = new RequestOptions();
requestOptions.StripeAccount = "{{CONNECTED_STRIPE_ACCOUNT_ID}}";
service.Create(createOptions, requestOptions);
Stripe only charges the $2.00 fee on active Connect accounts - i.e. ones that you either transfer money to or customers do direct charges to. As such, there is always a monetary transaction before the Stripe Connect charges are accumulated.
In your case (and mine, actually) you are using separate charges and transfers - so withhold an amount equal to the $2.00 charge the first time you transfer to an account each month (a little bit of database/bookkeeping), as well as a "guess" at the payout charges as well (a "guess" because you know when you transferred money, but don't necessarily know how they will be combined into payouts).
2022-01-20
Pseudo-code:
//if using multiple charges to a single vendor
=> collect charges filtered by transfer_group, summing available, pending, fees, then net as AVAILABLE
=> collect existing transfers by transfer_group, summing amounts as ALREADY_TRANSFERED, and gathering transfer Id's
=> we'll use AVAILABLE_TO_TRANSFER = AVAILABLE - ALREADY_TRANSFERED
=> check Connect Account receipt records (your database) for previous transfers in this calendar month (I did mention bookkeeping)
=> if there are no other receipts, then what we'll set BASE = CONNECTED_ACTIVE (currently $2)
=> the amount we will transfer is the AVAILABLE_TO_TRANSFER less reserved fees
=> We know the potential Payout fees will be based on the amount actually transferred (might be less if transfers are collected into a single payout - remember I said pessimistic)
=> The Payout Fee (which we will save as RESERVE) will be based on the actual transfer, FEE = BASE + PER_PAYOUT + PAYOUT_RATE*PAYOUT, with the pessimistic assumption PAYOUT = TRANSFER. PER_PAYOUT is currently $0.25 and PAYOUT_RATE is currently 0.25%.
PLEASE PLEASE PLEASE put the actual values in a database somewhere and use variables to pass into the formula - that way you can easily maintain your code.
=> So now we know AVAILABLE_TO_TRANSFER, and we know that TRANSFER = AVAILABLE_TO_TRANSFER - RESERVE, and we know that RESERVE = BASE + PER_PAYOUT + PAYOUT_RATE*TRANSFER
=> a half-page of algebra, and we can get
RESERVE = (AVAILABLE_TO_TRANSFER*PAYOUT_RATE + (BASE + PER_PAYOUT))/(1 + PAYOUT_RATE)
and
TRANSFER = AVAILABLE_TO_TRANSFER - RESERVE
As mentioned, you do need to keep receipts in your database to know if the Active Connected Account fee needs to be collected. Keep the reserves in your platform account until the monthly Connected Account & Payout fees are charged, reconcile the # of actual payouts against the pessimistic guesses above, and you can the withdraw (payout) any excess from your platform account.
2022-01-20a
you can be even more pessimistic (by a small amount) and just use
RESERVE = BASE + PER_PAYOUT + PAYOUT_RATE*AVAILABLE_TO_TRANSFER
You'll just reserve a tiny amount more than you have to - which we are kinda already doing anyway...
BIG NOTE
This is NOT official advice from Stripe - I do not work for them. This is my approach.
You can specify an application_fee_amount to collect a fee for a Direct Charge.
With Direct Charge, the connected account will pay the Stripe fee, and you as the platform will get the application fee that you specified in the Payment Intent creation.
I'm working on node api, and facing concurrent request problem.
pseudo code
1. Get user details along with credit balance.
2. Get contest maxEntry count (1 user = 1 count), total no. user joined contest so far, maxEntryPerUser, and contest entry fee.
3. Compare user credit balance and entry if balance is low then throw error
4. Compare maxEntry and totalJoined, if maxEntry is less or equal to totalJoined then throw error and not allow user to join the contest otherwise allow.
Problem 1: Suppose user have 2 credit balance and contest entryFee is 2, maxEntryPerUser is 1
user have credit balance 1, and user sent 100 request concurrently, all 100 request started processing parallelly, out of 100 more than 50 request get process successfully i.e. same user joined the contest more than 50 time with low credit balance
Expected result: 99 request must get failed and only 1 request should get success response.
Problem 2: Suppose maxEntry count 1
Multiple users sent 100 request concurrently, all 100 request started processing parallelly, out of 100 more than 50 request get process successfully i.e. more than 50 users joined the contest whereas there was only 1 entry allowed
Expected result: 99 request must get failed and only 1 request should get success response.
This can easily be solved by running the check and the data modification in the same REPEATABLE READ transaction. Then all but one transactions will get a serialization error and have to restart.
If you expect conflicts that often, it might be better to use SELECT ... FOR NO KEY UPDATE in the check to ensure that only one check can run on the same data at the same time.
The docs provides the code below, but I believe if I switch from a $10 / month membership to a $100 / year membership, it will make the switch immediately, and reduce the yearly package by the cost of any unused time from the original membership.
As there is no difference in content between the 2 packages, just an opportunity to save a bit of money by committing to a full year, I want the existing membership to continue until the month ends and then I want it to charge them the $100 and increase their billing cycle from monthly to yearly.
Does anyone know how to do this?
Here's the docs...
const subscription = await stripe.subscriptions.retrieve('sub_49ty4767H20z6a');
stripe.subscriptions.update('sub_49ty4767H20z6a', {
cancel_at_period_end: false,
proration_behavior: 'create_prorations',
items: [{
id: subscription.items.data[0].id,
price: 'price_CBb6IXqvTLXp3f',
}]
});
I'm using MongoDB and I'm quiet new to it, so I'd like your help on how to model my data. What is the best efficient way?
Here is my use case.
Let's say I have three income sources, named Income1, Income2, Income3. Tomorrow they might be 4 or 20. Each new Income source will suppose new integration to be implemented.
Let's say I have ten users, named User1, User2... User10. Tomorrow they might be 1000. (I hope ;-)). Here, no integration needed for a new user.
And let's say that I'm interested in storing, for each day, how much money User1 got from Income1, Income2, ... User2 from Income1, Income2... and so on. And even some day I'll aggregate all of this.
Still following me?
How should I model this?
First idea: Separate collections and separate documents
3 Collections : Income1, Income2, Income3. If an Income4 comes up, no problem, since I'll have to add some code, I can also create a new collection. Not an issue.
In each collection, the data for a user, with one document per user and per date, like this:
Income 1
{name:'user1', date:'2014-12-07',money:'24.32'}
{name:'user1', date:'2014-12-08',money:'14.20'}
{name:'user2', date:'2014-12-07',money:'0.00'}
{name:'user2', date:'2014-12-08',money:'0.00'}
{name:'user2', date:'2014-12-09',money:'10.00'}
{name:'user3', date:'2014-12-09',money:'124.32'}
Income 2
{name:'user1', date:'2014-12-05',money:'4.00'}
{name:'user2', date:'2014-12-06',money:'0.20'}
Second idea: Separate collections, and same document + embedded document
3 Collections as before. In each colection, the data for a user, with ONE document per user:
Income 1
{name:'user1', incomes:
[{date:'2014-12-07',money:'24.32'},{date:'2014-12-08',money:'14.20'}]}
{name:'user2', incomes:
[{date:'2014-12-07',money:'0.00'},{date:'2014-12-08',money:'0.00'},{date:'2014-12-09',money:'10.00'}]}
{name:'user3', incomes:
[{date:'2014-12-09',money:'124.32'}]}
Income 2
{name:'user1', incomes: [{date:'2014-12-05',money:'4.00'}]}
{name:'user2', incomes:[{date:'2014-12-06',money:'0.20'}]}
Third idea: SAme collection, and separate documents for everyghing.
{income_type:1,name:'user1', date:'2014-12-07',money:'24.32'}
{income_type:1,name:'user1', date:'2014-12-08',money:'14.20'}
{income_type:1,name:'user2', date:'2014-12-07',money:'0.00'}
{income_type:1,name:'user2', date:'2014-12-08',money:'0.00'}
{income_type:1,name:'user2', date:'2014-12-09',money:'10.00'}
{income_type:1,name:'user3', date:'2014-12-09',money:'124.32'}
{income_type:2,name:'user1', date:'2014-12-05',money:'4.00'}
{income_type:2,name:'user2', date:'2014-12-06',money:'0.20'}
These are some ideas. I'm sure there are others.
I will often have to query per user, on the most recent documents (i.e. with the most recent dates). I may from time to time need to aggregate information per week, month.... And, finally, I think I'll update the table from a cron running every night (to add the coresponding income for each income source and user)
Is this clear? I come from a relational database background (is it so obvious?) so maybe there is something I haven't even considered.
Thanks in advance.
At this point I would recommend the third idea. Rolling the data up per-user and / or per income stream is quite simple using the aggregation pipeline. Working with sub-documents is more pain than it's worth in my experience.
I just had a transaction that completed. The transaction Id was reported through the webhook as a an integer XXXX132. When I look at the Dwolla site of the recipient, on the receiving side the id is XXXX131 and the .25c fee has the id XXXX130.
Can I assert that for any transaction the ids are numeric and the relationships are:
Fee id: N
Receivers's id: N + 1
Sender's id: N + 2
If not, how do I determine all the ids since the web hook only reports one of them.
You are correct. We create transactions in the following order: Dwolla fee if necessary, facilitator fee if necessary, receiver, sender. Be careful assuming SenderId - 2 is the Dwolla fee because for transactions <= 10 it will be some random transaction, not the fee for your transaction.
This is subject to change at any time so I wouldn't make crucial decisions based on this information.