I am selling a high volume product that costs a minimal amount per piece. ($0.001 USD each to be exact).
I allow my customers to purchase a one time amount of product or a recurring payment amount of product at their desired choice of USD per payment.
How can I limit my customers to only spending $10 USD or more per payment through PayPal? They limit it at $10,000 USD, can I limit it at $10 USD?
Right now, I am not processing payments of less than $10 USD, and recommending that customers do not, but it is still possible to make them.
The problem arises when a customer purchases $1 worth of product and paypal takes 40 odd percent of that payment due to per-payment fees.
I do not believe PayPal offers a setting for minimum allowed payment. This is something you would need to handle on the server side. It would be easy enough to do. Just don't display the "Pay with PayPal" button unless the order total is $10 or more.
Related
I recently discovered Poloniex's API and am a big fan. I am puzzled about the following thing though: I query one Poloniex's BTC-ETH trade history for a 24h trading period. E.g., https://poloniex.com/public?command=returnTradeHistory¤cyPair=BTC_ETH&start=1489190400&end=1489276799 queries all BTC-ETH trades on March 11, 2017 (UTC). The returned JSON contains 46,675 trades (below the API's max result size of 50k). When counting up all the sell- and buy-trades contained in this JSON, I see that there is a total of 8,814.124270 coins bought vs 7,754.184259 coins sold. How can that be? Shouldn't those two numbers be the same? What am I missing?
Thank you very much in advance.
A buy is when someone buys the ask, also known as an uptick.
A sell is when someone sells the bid, also known as a downtick.
Everything that is stuck on the book is considered liquidity. Market price buyers and sellers remove liquidity. People who put orders on the book add liquidity.
So no, the buys should not equal the sells as it is totally possible that all that happened one day is that everyone kept hitting the buy button.
Consider this, if the buys equalled the sells, why would you need the data sent twice, and how would you know whether the bid or ask was taken?
I am working with money expiration tracking problem at the moment (originally it is not money, but I have used it as a more convenient example).
An user can earn money from a platform for some mysterious reason and spent them for buying stuff (products, gifts etc.).
I am looking an algorithm (SQL query best case) to find a current balance of an user balance.
The events of spending and earning money are stored different database (MySQL) tables (let's say user_earned and user_spent). So in normal case, I would simply count user totals from user_earned and subtract spent money (total of user_spent).
BUT! There is a condition, that earned user money expires in 2 years if they are not used.
That means, if user have not used his money or used just a part of it, they will expire. If an user uses his money, they are used from the oldest not expired money record, so the balance (bonus) could be calculated in user's favor.
These are 5 scenarios with events in time, to have a better understanding on the case:
Both tables (user_earned and user_spent) have timestamps for date tracking.
I did something similar in one of my projects.
Looks like you need an additional table spends_covering with columns
spend_id, earhed_id, sum
So for each spends record you need to insert one or many rows into the spends_covering to mark 'used' money.
Then balance would be just sum of not used where date is less than 2 years.
select sum(sub.earned_sum-sub.spent_sum) as balance
from
(select e.sum as earned_sum, sum(sc.sum) as spent_sum
from earned e
left join spends_covering sc on e.earhed_id=sc.earhed_id
where e.date BETWEEN ...
group by e.earhed_id
having earned_sum > spent_sum) sub
It may be worth it to have two tables -- one (or more) with all the historical details, one with just the current balances for each 'user'. Be sure to use transactions to keep the two in sync.
I'm trying to wrap my head around the proper way to design tables for a billing policy where the customer can pay for each delivery as they are completed, or they can receive a monthly invoice with the entire balance due. This is a small bit of what I have already...
I'm not sure where to go... should I create a table for paid in full and monthly statement and relate them to the invoice table... or should I relate those to the payment table... or am I all over the place....
It's a lot more complicated than you think. You also have to account for partial payments, overpayments, payments on account, refunds and other real world complications.
The only way to approach this which will actually reflect the ugliness of the real world is to treat individual charges as one thing (your deliveries), summary documents (monthly invoice/statement) as another thing, and payments/refunds as another thing.
From there you need to join these three separate things together with relationships. The temptation is to join monthly invoices to payments, directly, but that would be a mistake. At least, it would make your life more complicated than it needs to be.
The relationship between charges and invoices is relatively easy. If your customer gets a monthly invoice, then all their packages from that month point at that invoice. This makes a many to one relationship from Package to Invoice.
The more complex part is the relationship between payments and charges. For this you need a new table Payment_Application which is a many-to-many intersection between charges (Packages) and Payments. This intersection entity will also have the amount of money paid for each package. This is important because you can record here whether the amount paid was too much, too little or the correct amount.
If you want to get more sophisticated, you could normalize the payment information so that you have a payment header and detail. This lets you keep information about a payment you receive separate from information about how you choose to apply that payment.
Consider the following:
Here you have an (optional) invoice header and an invoice detail (Package) as well as a payment header and an (optional) payment detail, which may or may not relate to an invoice detail. An arrangement like this will cover the various ugly things that happen when you need to track the exchange stuff for money.
So here is the basic question:
US Federal Income Taxes can change yearly, or even in mid year. They're based on Tax Tables, whether or not you're single or married, how often you get paid and how many allowances you claim. Here is an example Tax table for someone who is Single and gets paid Bi-Weekly (for 2013):
Gross income between $42 and $214 - $0.00 plus 10% of excess over $85
Gross income between $214 and $739 - $17.20 plus 15% of excess over $214
Gross income between $1479 and $3463 - $191.95 plus 25% of excess over $1479
Gross income between $3463 and $7133 - $687.95 plus 28% of excess over $3463
Gross income between $7133 and $15406 - $1715.55 plus 33% of excess over $7133
Gross income between $15406 and $15469 - $4445.64 plus 35% of excess over $15406
Gross income between $15469+ - $4467.69 plus 39.6% of excess over $15469
So the different pay schedules are Weekly, BiWeekly, Semimonthly, Monthly, Quarterly, Semiannually, Annual and Daily. There are two tax tables per schedule (Married and Single) with different figures in each.
So, to calculate a payroll you have to pull in an employees Deductions (health insurance, etc) Pay type, Pay schedule, garnishments (if any) then take the range of their gross pay and figure out where in these tax tables that figure falls then calculate taxes.
What is the best way to setup the DB so I can edit any or all of these figures as needed - but at the same time not make my SQL queries 100 lines long when trying to calculate a payroll for a group of employees? (If possible)
Create a table for each Pay Schedule? Two tables (married and single) for each Pay Schedule? At this point I think that is the way to go, but I just want to make sure I'm not over complicating. Any or all advice welcome. Thanks in advance.
I have done complete payroll (Indian)primarily using MySQL stored procedures...
Based on my experience
Using stored procedure it can be done (will reduce considerable code)
Sum (total)Income from monthly/bi-monthly table payout..
Create a separate table for all exemptions.
You can use if / case condition to calculate tax based on your requirement.
Hope you have employee personal data table, you can store Married or Single status, while calculating tax you can pull from there.
If you wish will paste my code
Assume a simple database for hotel reservations with three tables.
Table 1: Reservations
This table contains a check-in and check-out date as well as a reference to one or more rooms and a coupon if applicable.
Table 2: Rooms
This table holds the data of all the hotel rooms with prices per night and number of beds.
Table 3: Coupons
This table holds the data of all the coupons.
Option #1:
If you want to get an overview of the reservations for a particular month with the total cost of each reservation, you'd have to fetch the reservations, the rooms for each reservation, and the coupon (if one is present).
With this data, you can then calculate the total amount for the reservation.
Option #2:
However, there is also another option, which is to store the total cost and discount in the reservation table so that it is much easier to fetch these calculations. The downside is that your data becomes much more dependent and much less flexible to work with. What I mean is that you have to manually update the total cost and discount of the reservation table every time you change a room or a coupon that is linked to a reservation.
What is generally recommended in terms of performance (option #2) version data independence (option #1).
UPDATE:
It is a MySQL database with over 500 000 rows (reservations) at this point, but is growing rapidly. I want to optimize database performance at an early stage to make sure that the UX remains fast and responsive.
Let me start to answer this with a story. (Somewhat simplified.)
2011-01-01 I reserve a room for two nights, 2011-03-01 and 2011-03-02. You don't tell me which room I'll get. (Because you don't know yet which room I'll get.) You tell me it will cost $40 per night. I have no coupons. You enter my reservation into your computer, even though you're already fully reserved for both those nights. In fact, you already have one person on the waiting list for both those nights. (Overbooking is a normal thing, not an abnormal thing.)
2011-01-15 You raise the rates for every room by $5.
2011-02-01 I call again to make sure you still have my reservation. You confirm that I have a reservation for two nights, 2011-03-01 and 2011-03-02, at $40. (Not $45, your current rate. That wasn't our deal. Our deal was $40 a night.)
2011-02-12 One person calls and cancels their reservation for 2011-03-01 and 2011-03-02. You still don't yet have a room you know for certain that I'll be able to check in to. The other person from the waiting list now has a room; I'm still on the waiting list.
2011-02-15 One person calls and cancels their reservation for 2011-03-01 and 2011-03-02. Now I have a room.
2011-03-01 I check in with a coupon.
You can store the "current" or "default" price with each room, or with each class of
rooms, but you need to store the price we agreed to with my
reservation.
Reservations don't reserve rooms; they reserve potential rooms. You
don't know who will leave early, who will leave late, who will
cancel, and so on. (Based on my experience, once in a while a room will
be sealed with crime scene tape. You don't know how long that will last, either.)
You can have more reservations than room-nights.
Coupons can presumably appear at any time before check out.
If you want to get an overview of the reservations for a particular
month with the total cost of each reservation, you'd have to fetch the
reservations, the rooms for each reservation, and the coupon (if one
is present).
I don't think so. The price you agreed to should be in the reservation itself. Specific rooms can't resonably be assigned until the last minute. If there's one coupon per reservation, that might need to be stored with the reservation, too.
The only reporting problem is in making sure your reports clearly report how much expected revenue should be ignored due to overbooking.
The response of your answer depends of the size of your database. For small database option #1 is better, but for huge database option #2 is better. So if you could say how many rows you got in table, and the database used (oracle, sqlserver etc.) you will have a more precise answer.
You can add a table holds the data of the rooms`s historical prices and reason for change.
Table 2 only records the latest price.