So I have this problem which is bugging me for past few days.
I'm trying to make a recurring payment for X month of time with Paypal.
Recurring payment itself is working find with Billing Plan and Billing Agreement, but the problem happened in the next stage.
It needs to total up to X amount of money.
So for example, If a customer wants $100 to be paid over 3 months, it will $33.33 monthly and this will total up to $99.99, not $100!
Therefore I was trying to find something that would make me allow to change the last month payment but there was no luck.
Last thing I was going to try was making two separate payment definitions (trial and regular although they both are not trial) and set one as different amount.
Is there any better idea of implementing this feature or anything I couldn't find?
And one more question - what is the difference between trial and regular payment? I know what they mean but what's different in payment wise/program wise? Can I make regular payment definition as trial so I could just have trial payment with different $$$ and then when trial ends, proper regular payment goes through?
A trial period will work for what you propose, the only disadvantage is that the verbiage might confuse the customer during checkout, since they will see it broken down that way.
what is the difference between trial and regular payment?
The difference is that one is called 'trial' and one is called 'regular', and one happens before the other. So basically, no other important differences so long as the system accepts the parameters you're setting.
FWIW, most customers would appreciate you rounding down each period and just charging them 33.33. They would think that's fair enough.
Related
I have a question. How can I show certain shipping rates, based on a weekday in shopify checkout. For instance, I would like shopify to show different shipping rates on weekends, which are more expensive.
I know it should be something like this pseudocode:
Get current day of week
If day equal to Saturday and Sunday
{show these weekend shipping methods}
else
{show regular shipping methods}
Can anyone help me with the script?
Typically what we have done for a decade or so is install a custom carrier service for that purpose. By doing that, Shopify sends your App the origin, destination, and payload, to which you respond with JSON about pricing. So you get to take into account the number of days to delivery, the service levels, and how much to charge, based on delivery being a weekday or weekend.
It maybe different in 2022, but I kind of doubt it, so if you indeed control your own Shipping Rates and service levels, and want to present better numbers to customers, just put a custom carrier service into play.
I have a collection of items which has a 13% tax. So if you buy $1 in goods, your final charge would be $1.13 because of this tax.
I give users the option to return certain items while purchasing others (imagine returning the keg of beer while buying another).
The problem, however, is that the "return" (where I subtract $X from the checkout) affects the checkout pre tax. So if the total was $100, which is $113 after tax, my current code would deduct $50 pre-tax, which would affect the tax I need to collect.
Is it possible to have the items purchased + tax show in the checkout, and subtract the "returns" after the price plus tax is calculated?
I have looked at this link identifying a similar issue and people claiming they can solve it. The only solution provided by shopify was to pay $2000/month to get access to checkout.liquid where * maybe * I could solve the problem.
Unfortunately, your question is unclear. You have to understand how Shopify works to accomplish certain goals. One, you cannot mess with the pricing of goods or taxes. About the only thing you can offer customers are discount codes.
Anything that gets committed to checkout is out of your control. You cannot adjust anything in the checkout, with the exception being, Plus merchants can indeed script checkout, and even alter the Liquid.
Until you are more clear about what you are attempting, I suggest you ensure that whatever you are doing, the cart is fair game, do as you wish. Have the customer replace one item with another. Submit to checkout. Be done.
Sure, there are cheesy Apps that help fake things financially by using discount codes, but that is often a road to more problems than it is worth.
we have tried this but it did not work for us.
We then ended up disabling the tax altogether
The items were calculated inclusive of tax and we would then provide a tax invoice separately using API
I am making changes to my companies internal paysite in order to come into compliance with the new credit card regulations. We have decided that when we get a split tender transaction that comes through we want to get the remaining balance along with how much was on the card to start out with and send that info back to the customer service rep with a message relaying the need for another payment source along with the remaining balance and the amount that was originally on the card.
Instead of chaining the transactions together with the split tender Id we have decided we would like to finalize each split tender transaction with a prior_auth_capture and then request the next payment source and amount and process that transaction in the same manner. I know that we are side stepping the functionality some but those are my orders.
My questions are, is this feasible and possible and how do you do this in code? I am using the C# SDK to implement this in VB.NET 2008
My thoughts are that I would have to process the transaction for the amount passed as a auth_capture transaction and then some how do the prior_auth_transaction with a zero amount or something?
How would this work?
Thanks for much for your help.
James
This is not feasible to do. The purpose of split tender payments is to logically group together split payments into one transaction. By breaking it up into multiple transactions it can get confusing for you, the users, and the processor. Especially if you have issues getting the user to make full payment on their transaction. Failing to void the other transactions would be very problematic. This almost certainly will result in an increased exposure to chargebacks.
Recently a bug in our web store caused the prices to be doubled at checkout. This lead to a drop in orders from about 25 to 2 over a period of 19 hours. We have lost quite some money over this. What I wonder is: is there any way to measure how many of those "dropped" customers will come back and re-place their orders?
If they logged in, their user details. If not, compare IP addresses from your server log, IPs which left without buying during the price doubling, to IPs in the next week, to get a rough idea.
I would say if your product is good your customers will come back. I would say now is a good time to start collecting some analytics on your site. You won't have much to compare to but it would be a place to start. To tell if your customers are coming back you could compare the purchase data from before the issue to after. I would think you'd have some type of userid they would have to either log in with or enter when purchasing. Our sites all require a username to login, we also offer a guest checkout which is just an email address but we could comparisons if we needed to.
A non-programming solution is to offer customers who had the problem some kind of discount or additional product if they finalise their order. This doesn't help you find out how many come back because you are changing the rules, but it will help you lose some of the lost money.
If you have a mailing list, mail out the special offer, else put it up on your website somewhere.
Ask them to fill in the details of the order again, if it matches a previous order in that time period offer them the special deal.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I'm building a simple accounting app to be used for personal finance.
A user might keep track of purchases, upcoming bills, recurring deposits, etc. It will be verrrrry simple.
Two questions:
1) Any advice I should keep in mind? Obviously, I'll use transactions where appropriate, but proper datatypes and other considerations would be nice to know about.
2) Are there any APIs you know of I could use to periodically get a user's balance from their bank? i.e., an API that would make it simple to query their account, regardless of whether they're at Chase, BofA or other?
Thanks very much,
Michael
Having just completed version 1.0 of some custom written online accounting software for school related non-profits I have some advice :)
Use standard double entry accounting/bookkeeping (debits and credits) as the basis for your financial engine. You will find this will serve you well when it comes to not only storing data on transactions but also generating reports. Assets = Liabilies + Equity is a tried and true approach for tracking who owns what.
Use decimal types for money.
Use transactions.
Keep the interface as simple as
possible.
You will need to have a method to
allow the user to reconcile the bank
records with their own records.
Pulling in bank data would help this
process but you will need to provide
the user with a method to compare.
You can use bank statements for this
process.
The bank is always considered to be right.
If there is a discrepancy between
the bank and the user records... the
fault almost always is with the user
records.
Make sure you provide some sort of
backup facility for the user
Secure the users data
Make sure you fully understand the process you are automating. Do not make assumptions. Run your ideas by an accountant who specializes in personal finance. Having this vetting will help quite a bit.
Be prepared to write ALOT of code. Accounting software has been around for years, the list of "standard features" for a typical accounting package has grown, and there are quite a few players in the market. If you are planning on selling this product you will need to provide those standard features and then find some way of differentiating it from what is already available with additional features.
TEST TEST TEST and TEST again. You
are keeping records of peoples
personal financial transactions
(their money). Errors are not taken
lightly.
I will add a few tips as I am finishing a POS system that focuses on ACCOUNTING - meaning the purchases, expenses, invoicing, accounts, credit cards, cash, vehicles, etc all need to be tracked. The concepts will eventually be applied to a personal system.
The best advice is to look at your paperwork and try to form your database around what you need to do to translate your physical documents to the computer. Combine this with the first couple of chapters of an accounting textbook which talks about accounts, chart of accounts, and journals.
The books I used :
Accounting at your fingertips by George Murray
Finance and Accounting for Entrepenuers by Suzanne Caplan
Introduction To Accounting by Ainsworth
Accounting, Information technology, and Business Solutions By Hollander
Once you have your source documents entered into the system you can then run queries to get to your answers. Doing this eliminated the concept of the "General Ledger" and "trial balance" because you simply correct or add to your source documents. So the "General Ledger" becomes a calculation. That was super confusing to me. Again, all the source documents will be put into 'Journals', which can be your database tables. I use a general journal, a purchases journal, a payments or cash disbursements journal, a sales journal, and a cash receipts journal. Keep in mind the term "CASH" refers to cash, credit, check, debit.
For example I have a "general journal" which is basically what you need. In this journal I keep track of 'source receipts'. A receipt might be an invoice, like time warner cable, which has an account number. In that case I create an 'account' for time warner. The time warner account will link to a 'chart of accounts' which will specify the type of expense as "internet". The invoice then gets entered with the date, the amount, etc. The invoice links to the account for time warner. Once the invoice is entered it is unpaid. You then need to add payment. Of course you could pay the bill in full as you should, but you might need to do two payments, or split payments, or not pay in full. This will lead you to a 'Payments Journal" in combination with a 'invoice to payments lookup table' which will need to have an applied amount to apply to an invoice. This applied amount is important because you might have 4 unpaid time warner bills and you just send over $200 in a panic to get your account back on. This payment then needs to split across the invoices with amounts to apply to each. And of course the payment account will link back to your accounts.
For the case of entering a receipt, the account is not used. Say you pick up some lingerie at embrasse-moi, and pay cash. Your system will take the supplier, embrasse-moi, the date, the cost, I added a 'use tax' in case you purchase over the internet and did not pay tax but you still owe it, the amount, and the 'Chart of accounts' which is essentially what category is your expense. That all goes to the general journal. On the same form you will have the payment method. I made a simplified form for an expense + exact payment as that is very common. If the payment is split then you will need to enter the receipt using one form, then create multiple payments linking to that receipt with other forms.
So in the end your database for this simple accounting app will have the following tables:
Accounts (the account information including an account type like cc/debit card, checking, cash, inventory account for business purchases, expense account like utilities, the default chart of account)
Chart of accounts (basically a list describing how to classify expenses and accounts which will flow to your operating statement, i put mine here for you to check out:
http://embrasse-moi.com/exampleData/pos_chart_of_accounts.csv)
I have a table for opening balances for accounts, because you have to start somewhere
Account type - meaning credit card, debit card, etc. Keep in mind the accounting equation basicaly switches based on the account. Checking accounts debits are "bad" because you gave away your money and credits are "good" because you took in money while credit cards debits are "good" because you reduced your debt and credits are "bad" becasue you added to your debt
Chart of account types, which is an 'asset, liability, long term asset, etc. This could be included in the cart of accounts as an Enum type
Then there is the general journal, which as described contains enough information to describe your document. Is it on account? Date, amount, the type (receipt or invoice) due date, i keep a 'paid' flag to ease the querying.
Then you have a lookup between the 'general journal' table and the payment table
Then you have the payment table.
Once you have all this information in, you will almost never use your bank as sources, as they are not always correct, at least my bank makes mistakes. So this type of structure will keep you on top of your information, and at the end of the month this system will produce a statement that looks identical to your account statements. And that is the goal.
About APIs for getting info from your bank: not simple, if at all possible. You can imagine the lengths your bank will go through to make sure everything is secured. I don't think it'll be possible to automatically connect.
Usually there's a way to download data through manual downloading of a file, after you logged into your online banking (if you have that available). Hopefully it'll be in CSV format or something similar ;-)
[edit]
Apparently I was wrong here, major banks DO allow direct connection. I guess you'll have to consult your bank techsupport on that then.
[/edit]
As for datatypes to use, I'd at least recommend decimals for money values, instead of doubles/floats. see this SO question thread about that too.