I am trying to display a users transaction history in binance, including fund deposits and withdrawals as well as buying and selling of different crypto's. Does anyone know which binance API endpoints I would use to do this? It seems quite complicated in comparison to other trading platforms.
Thanks
This is the link to the docs: https://binance-docs.github.io/apidocs/spot/en/#withdraw-history-supporting-network-user_data
I can see the Wallet endpoints "Withdraw" and "Deposit", but this won't cover crypto trading will it?, The account trade list call would be ideal, but it requires a symbol input which I'm not sure how I would obtain dynamically.
I would also like this endpoint to provide me with the data so I can get the avg buy price for a crypto
Currently this is not supported. See: https://dev.binance.vision/t/fetch-all-account-orders/279/3
This is the route you're looking for to get the user trade history. The big downside is that you have to specify the exchange symbol, you cannot get the history of the account with just one request:
https://binance-docs.github.io/apidocs/spot/en/#account-trade-list-user_data
Get your account information first. You can then extract non-zero balances from here to get symbols for transactions. You can then loop through each currency pair and get its transaction history. This seems to be the most optimistic way we can get right now
You can also try to use caching. For example, you can remember balance for a particular coin, and if it has not changed by the next launch, then it is likely (but not 100%) that no transactions were made with it
You can also connect to WebSocket, but this is still a terrible crutch and requires a DOS attack to get the necessary data
Please note that here the balances for Savings wallet have LD prefix added to their ticker. For example, BTC in the Savings wallet is labeled as LDBTC
I'm currently evaluating using Plaid or Yodlee for transaction aggregation (I'm using the Dev environments for both right now). I really prefer almost everything about Plaid, but I'm having trouble with transaction name/description. Yodlee has a data field called the "simple description":
From their docs: "The transaction description that appears at the FI site may not be self-explanatory, i.e., the source, purpose of the transaction may not be evident. Yodlee attempts to simplify and make the transaction meaningful to the consumer, and this simplified transaction description is provided in the simple description field."
I'm displaying the transaction name to my end-users and I'm looking for something more user friendly than the transaction name field which often returns strings like "Withdrawal Check Card MOE'S BROADWAY BAGE BOULDER CO Date 01/06/19 0 9006020339 0 5812 Card [XXXX]".
I'm sure I'm not the first plaid customer to have this need. How do Plaid reliant apps solve this problem?
Plaid doesn't offer a simple description field as far as I know, but they do clean up transaction names.
I've found that when a new pending transaction comes in, the name is messy like you mention (e.g. UBER *TRIP 5VVB2). But once the transaction is confirmed, Plaid normalizes it for common merchants (e.g. Uber). I don't know why Plaid doesn't offer this normalization for pending transactions, but I have brought it up with them before. Perhaps this is something that could change in the future?
A solution, albeit complicated, is to build a custom model that normalizes transaction names. That's what we are doing at Pluto Money to supplement Plaid's transaction data.
I received a direct response by email from Plaid Support:
Thanks for reaching out to us here on Plaid Support, I'm sorry about
our delay.
Our name field for each transaction represents our best effort to
balance detailed transaction information while providing a clean and
consistent API response. This behavior does vary across banks, both
due to bank behavior and our own integration quality. Generally at
larger banks our integrations do a better job at returning clean
transaction names with appropriate transaction detail but for some of
our smaller banks transaction names may be more "raw".
If you never want additional detail beyond the merchant/transaction
name in your app I would encourage you to implement some filtering on
Plaid's name field to make sure that no date- or account number-like
character strings pass through into your user facing stream.
I'm trying to use the Xero API to download all transactions to reproduce the general ledger in an external system so I can use it to reconcile figures within that system.
So far, I've got it downloading invoices, bank transactions, manual journals and credit notes, but it looks like bank transactions that are allocated as a payment against an invoice don't show up in the bank transactions API call. Is this correct or am I missing something?
If I do need to download Payments, there doesn't seem to be a paging method. Is this correct or am I missing something here?
Also, is there anything else that I need to download that might affect net movement on the general ledger?
Regarding the missing payments in bank transactions, this answer should help.
The Payments endpoint doesn't have paging according to the docs, just the If-Modified-Since header.
For our external system we started with the Journals endpoint (which should have everything that adjusts the GL) and supplemented it where needed with additional fields from other endpoints depending on the source type.
I understand Parallel payments are limited to 6 receivers but what about Chained, it only says multiple receivers.
We plan on having many items in our catalog and know that many will purchase more than 6 items, each items will be split by 4 , 1 will be developer but what if you had 12 items that 3+(1*12) which would be 15 receivers. Is there a way to do this?
Also can you have each account pay their own amount on the fees or does the primary get stuck with the whole thing?
Thanks,
Jeff
The Pay call in general is limited to 6 receivers. PayPal may be able to open that up for you but you'd have to discuss that with them during the process of applying and getting your live App ID for your app.
When working with the Pay API you can use the feesPayer element to specify how to handle the fees.
If Adaptive Payments -> Pay simply won't work out for you, you could go ahead and setup a regular checkout system where the buyer sends you all the money, and then you could automate the process of sending money from that out to the people who need it from the order using an IPN solution.
You'd still be limited to 6 receivers in a Pay request, but you could make multiple Pay requests within your IPN script. Alternatively, you could use the MassPay API to send money to up to 250 people at a time.
With MassPay, though, the sender pays the fee, but the max fee no matter how much the amount is would be $1.00. You could simply work that (and the original payment fee) into your deal with your partners so that the fees get split up accordingly.
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.