I have sample XML transactions for "buy" and "sell", but Yodlee provides many, many, many different type of transactions. What XML should I use to simulate a 401k contribution transaction?
You can definitely check with Yodlee Support team and ask them to share an xml which may have some more details and you can use the same under your DAG. This will allow you to test such transactions for that specific type of accounts.
Related
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.
With multiple SQL operations (such as a bank transfer or a purchase of a shopping cart full of products) the developer needs to bracket the operations within a Transaction and they either 1) all succeed (Commit) or 2) all fail (Rollback).
So, my question is what is UoW adding to this principle or how does it differ and do we need to implement the transaction support explicitly when using UOW in business problems like bank transfer or shopping cart when somebody will place a order?
I believe you should have a mechanism to handle each request as different session. If you are using .net you can refer to below link for how to handle session state. https://msdn.microsoft.com/en-us/library/ms178581.aspx
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've been researching eCommerce payment gateways and service offerings, but I'm an eCommerce novice, so please excuse my ignorance.
I wish to set up an eCommerce solution with the following requirements:
User "subscribes" to the service on a yearly basis. This service includes a single product subscription for a set amount (let's say $50/yr).
User can "subscribe" to additional product services for a lesser rate per year (let's say $25/yr).
I will need to store a product service unique Id of some sort for each product subscription the user subscribes to in order to show them product unique information. I also need to prevent duplicates...for example, user can subscribe to product ABC and XYZ, but not 2 of ABC.
Is PayPal the best solution for something like this? Is there a better solution? Any assistance is greatly appreciated, even if just links to specific tutorials or examples.
Update: It looks like Chargify could be the perfect solution.
You can also use Authorize.Net's CIM solution which, based on what I read at the chargify website, does most of what chargify does except your customers never need to leave your website. The Customer Information Manager allows you to create profiles for your members. These profiles store sensitive information like credit card numbers and billing information so you don't have to worry about PCI compliance or hackers stealing your information. You then can schedule a cron job to charge them monthly for whatever amount they owe based on their current subscription. Since you control when the payments happen it also allows you to charge them pro-rated amounts for subscription changes mid-month.
[link text][1] seems to be the best solution for me. I still need a merchant account, but this takes a lot of the headache out of handling the subscriptions.
[1]: http://chargify.com Chargify