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.
Related
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 am just curious to know why Bitcoin developers choose a complicated approach like UTXO, rather than using the transaction models used by Ethereum Blockchain.
Basically, Bitcoin nodes maintain a set of all active UTXOs which have not been spent yet and any transaction that comes in is validated using this set. The nodes also update the UTXO set after every transaction.
This model is very analogous to how you'd implement a "wallet" which held currency notes and coins albeit with perfect traceability of each note in your wallet as to where you received it from! It is not complicated once you understand this basic analogy.
Consider the case where you have only a 20$ bill in your wallet. Let's say you buy a product worth 6$ with this 20$ bill. In this case, you will get BACK 14 $ in "change" and these notes are akin to the "unspent transaction outputs". These notes (UTXOs) can then be spent in any later transaction.
The advantage that UTXOs have is that each UTXO can be traced back right upto the point where the actual bitcoin was created (miner reward for example) and even upto the genesis block potentially.
This is akin to your being able to trace back the 20$ bill from where/whom you received it, and in succession being able to trace back how that person received this 20$ bill and so on and so forth until you traced it back to the Federal Reserve Bank mint where it was printed!
You can imagine how this would dramatically increase the security and trust in the system because you could validate each and every facet of a transaction.
However, this model was considered as not efficient enough for the Ethereum protocol which also has smart contract transactions which might execute frequently. Due to this, Ethereum went for a "Account state" based model which makes it far more efficient to calculate balances before and after transactions.
Here are some helpful links that might answer your question:
Considered as skewed towards a pro-ethereum viewpoint - https://ethereum.stackexchange.com/questions/326/what-are-the-pros-and-cons-of-ethereum-balances-vs-utxos
Also a Medium article which goes into more detailed comparison on the UTXO and Ethereum Account State model https://medium.com/#sunflora98/utxo-vs-account-balance-model-5e6470f4e0cf
Does yodlee provide any means for retrieving an actual bank statement (like a pdf) vs. the data contained in this statement? Due to some regulatory requirements, our intended users would need to confirm that statement information provided is complete. Currently this is done by asking for a complete statement from the banks' website, like a pdf print out. Does yodlee have any apis that could return statements unmodified vs the transactions and other information from the statement?
Thanks!
Yodlee provides APIs to retrieve the transactions & other statement related information like Amount Due, Due Date etc , while there is no such API which will provide you complete Statement in PDF format(As you receive from Bank itself).
So far I know Yodlee only provides transactions, you may create your statements by filtering for the specific periods. Yodlee does not download any statements but it get its transactions by screen scrapping method. So you'll receive transactions and then it is up to you to handle them according to your business needs.
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.
I'm considering asking for credit card details BEFORE an address for a physical product with average purchase price between $10-$50
What might be the technical (or non technical) issues surrounding doing this?
What comes to mind is :
This seems a little non-standard from the users perspective
We cant do address verification if we find we're having issues with fraud (not an issue so far)
Users may be more likely to complete the sale since they've committed to their most important piece of information first
By asking for zipcode we can populate city/state when we do ask for the address
Are there any dealbreakers i'm missing or things I'm not considering?
I'm trying to make the system as flexible as possible, but would prefer to getit right first time without barking up the wrong tree.
My advice to you is don't do it.
I often cancelled buy attempts and abandoned the sites when I got asked for my credit card number right in the face.
Often, the site is so poorly designed with no answers to obvious questions that you have to go through the complete form hoping to find answer in the process. Do they offer this particular shipment option? How much does this cost? Do they send to a package station or only to my home address? Do they provide an extra line for an address for me to use the "c/o" technique? I often could not find answers to these question anywhere on the site. So I either found them in the form before entering my payment details, in very few cases I did call them, in most others I just chose other places to buy from.
One more use case. In many places I've seen they only show you if they have an item on stock on the very last page of the order form. Not many people would want to "commit" to the payment right away without getting all the required information. You enter your credit card number, then on the second page you see they don't offer the shipment option you need, on the last page it says "the item is currently out of stock - delivery awaited in 3-4 weeks". And the order is already placed. Then it is a commitment from the user but not from the company, many will react emotionally to this approach as to scam and request their money back immediately.
The important thing is to behave friendly to your customers, don't scare them away, don't raise suspicions in them, don't make them regret they committed to their buying. Make them feel relaxed and happy and never with their arms bound.
This may seem non-standard from a consumer perspective, but this is perfectly normal in B2B systems. You can collect personal/company & payment details, then shipping & payment addresses, and then present the user with a final confirmation screen showing tax & delivery charges before processing the order. Only then do you process the credit card payment.
However, the issue that "New in town" mentions is a very valid one, where the customer is left thinking:
Hang on, why are you asking for my credit card details when I haven't seen the final amount yet?
I think this is perhaps down to a site not having a clearly defined order creation process (or at least one that is not clearly communicated to the customer), so that the customer is under the impression that by entering their CC details at that point, the payment will be processed there and then.
It may be best to do things the way other popular online stores do, Principle of Least Astonishment and all that, but if you really want to do it in this order then perhaps a simple progress bar to indicate order creation flow would help allay customer fears. Don't bet on it though, online consumers are rightly paranoid when it comes to their credit card details these days. ;)
As someone who has done quite a bit of online purchases, I can say that I would be extremely worried if a site first asks for my creditcard information before it asks for anything else. It tends to trigger my "Fraud Detector". Am not sure why this is, but I just get worried that the site is going to forget about asking for my address.
As mentioned, in B2B environments, this is a bit more common, though. Then again, in many B2B environments, the visitor first creates a business account before he even starts ordering. Part of setting up this business account is providing the creditcard information. To be honest, many B2B also provide services and digital downloads which don't even need a shipping address.
Many people use the ship to address page to determine if the site will ship to their region/country. They are not likely to bother giving CC info before they even know you'll ship to them.
I live in outside the US and MOST sites fail to recognize that there are customers outside of the US. Often the only way to determine if they will ship to me is to go through the order process to find out they have a finite list of "states" they will ship to and no "country" drop down.