I can't figure out what are the guidelines for when transaction data is updated on Yodlee. For bank accounts (checking, savings), how frequently does Yodlee go back to the bank to get timely data? I tested with my own bank, and the balance and transaction data can be out of sync for a day or more.
Also wondering if the update timelines are consistent across all banks or if they are on different update cycles?
Thanks!
Please check our Refresh Policy-
https://developer.yodlee.com/Aggregation_API/Platform_Overview/Refresh_Policy
Hope this helps.
Regards,
Krithik
Related
We are currently having a difference when loading data via Webservice / Rest from Xero to our own software:LucaNet and it is specifically from unrealized / realized gain and losses from Foreign currency. The reason being is that those values are being calculated by xero but not being posted as a transaction while we are pulling transactions from Xero to LucaNet. Hence we have a few differences in the Balance Sheet and PnL on some GL Accounts. Specifically Bank Accounts and PnL accounts for unrealized gain / losses.
Does anyone have an idea on that?
Help would be much appreciated.
BR
Andy
this issue sounds best answered by diving into the specific data of a request. The best forum for that is likely the Xero API tech support team.
You can start a case by emailing api#xero.com - include your client id and formatted data related to the discrepancy.
I am sorry if this wasn't a good place to ask a question like this, but since I always got help from Stackoverflow I though I could get some answer to my problem.
So here is the thing, I am building a e-commerce website like many famous websites over there, where you can make bid offers for items on the market.
The thing I want to be sure is that when someone place a bid for some item, they can not turn back on their word, because if they get accepted the money should be withdrawn from their bank accounts, do you get what I mean?
Because I want the merchant to be safe if they accept a offer they want the money, and they don't want to look for another legit offer.
So how can I accomplish this?
Should I ask the credit card details when they make the bid offer and only make the withdraw operation from their accounts if the their offer was accepted by the merchant? [using some automated trigger on my database of course]
If this is not the best practice to accomplish this, which is the one??
I am really new into payment methods and I just started doing my search for Payment Gateways (maybe they offer me this functionality... I don't know?!)
You should never store credit card details, and have the details is not really any guarantee of getting paid since the card could just be canceled.
What you are probably looking for is for Authorization and delayed capture (depending on the timeline you are looking at). Different payment processors have different time requirements around how long you can hold an authorization. In general you would make a request with the API to Authorize the charges (kind of like a 'hold' on your credit card) and then later you would either cancel or Capture, where the funds would be transferred. See more info about the process and Square's API here: https://docs.connect.squareup.com/articles/delayed-capture-transactions/
I'm looking for a way to allow our clients to do recurring payments to discount these payments based on the credit in their account which can be earned or deposited in many ways. For example, if they need to pay $20 and have $5 in credit, I would like to only bill the remaining $15 automatically without any need for additional website visits.
Looking at the documentation for PayPal's REST APIs, I don't see any clear way to do this. Is the only way to do this to send them a refund automatically? Or is there a way to get approved to bill clients up to X amount per month but allow us to bill under that amount. I thought billing agreements would allow for this, but after reading the documentation, I'm unable to figure out a way to do it. If it's possible, could someone walk me through what API calls would be needed to do this?
Thanks for any help you can offer.
There are a couple of different ways you could do this sort of thing, but I would avoid the REST API for now. It's still too new and doesn't provide as much functionality and features as the classic API.
Within the classic API, you can use either use Preapproved Payments, which consists of Preapproval and Pay APIs, or you could just use Express Checkout and/or Payments Pro with Reference Transactions.
Either way you'd basically be building your own recurring payments system where you'd setup a billing agreement and then your app would trigger the variable amount payments accordingly.
Is it possible to use PayPal's preapproved payments api for the following scenario:
Online marketplace where users buy fixed amounts of credits.
They spend the credits on items/services in the marketplace.
We detect when the credits run out and based on the billing agreement automatically charge them to renew the amount of credits.
I have spent quite a while looking around for an answer to this but cannot find my specific problem.
Any help very much appreciated! Thanks.
Yes this is definitely possible. I would write a cron job that periodically checks current credits against their billing agreement. If there is a match, then make a pay request to paypal. Sorry I cannot provide code examples without more knowledge of how your site is structured.
Before jumping in I'd like to know what all of my options are, and, if possible their pros and cons.
The two I know of are using ActiveMerchant, or the paypal_recurring gem, but will they satisfy these requirements?
Ability to accommodate monthly and annual billing
Ability to suspend, cancel accounts etc
Deal with out-of-date card details or failed payments
The to-do list for the paypal_recurring gem includes 'adding support for IPN' - how will not having this impact functionality?
I know there is the railskit SaaS but I'd rather code something myself as the railskit is still on 3.2.1.
I know there are services like cheddergedder/chargify etc, but do they tie you in? Are they US only? Are they worth considering - or are they usually just aimed at non-developers?
Thanks in advance.
I just finished going through this, so I'll try to shed some light on your options. I ended up using Paypal Express Checkout for all recurring purchases through Paypal. We had a custom-rolled recurring billing setup that charges a customer's credit card monthly through Authnet, but had to switch because we needed an international solution, and Paypal was one of the only ones that supported the currencies we needed, and wasn't entirely a nightmare to code.
You can use ActiveMerchant for recurring billing with this plugin, though keep in mind that it is not officially a part of ActiveMerchant, and therefore is subject to break if ActiveMerchant changes how it handles certain things. Because of that, I ended up using the paypal-recurring to handle communication through Paypal, and then rolled my own IPN parser, with help from Railscasts. Another link that helped me a lot was this, though all the :txn_type values ended up being different.
With regards to that last link, here are the 4 :txn_types that I specifically watch out for:
express_checkout - first postback.
recurring_payment_profile_created - sent on first postback when the user first subscribes.
recurring_payment_profile_cancel - sent if user cancels subscription from Paypal's site.
recurring_payment - Money has been transferred to your account. This is what I wait for before I renew their subscription on a monthly. This post also comes with payment_status, which needs to be completed.
The other stuff you mentioned, like handling failed payments and out-of-date cards, is handled through your Paypal account.
Just a word of warning - the only reason I ended up using Paypal is because it is universally recognized and trusted, and it accepted international currencies. There is an enormous amount of documentation on their site, and most of it is redundant, confusing, and entirely too long. My recommendation is to make sure you really want/need to deal with recurring payments, as they are difficult to implement correctly and can be more trouble than they're worth.
I'm currently looking at Ryan Bates example of Stripe. They are a California based company that uses/offers the features you have listed.
www.stripe.com
They only charge when you receive money. I think that they are 3% plus $0.30 per successful transaction. Much better than some other companies that have a monthly minimum. Right now you have to have a bank in the USA to use their services as a merchant. However, anyone can use your site with out of the country credit cards.
The SaaS Kit is now tested with Rails 3.2.2. :) It doesn't support IPN yet, but it's on to the todo list. With all the info here in one spot, I suppose I have no excuse not to get it done. :)