retrieve interest rates for credit cards using Yodlee - yodlee

I am using Yodlee to get the transactional history and summary of accounts for my clients to do some predictive maths on their debt levels.
Is it possible to get the interest rate for a credit card account? Looking in the data model here there are references to APR and interest paid to date.
However using Testdrive These fields are not being returned using: getItemSummaryForItem1 or getContentServiceInfo1.
The banks I am using are ANZ (NZ) and ASB (NZ) I would like to know if these sites do not support credit card interest rates, if they do please let me know what api calls I need to make to retrieve them.

As a data field interest rate(APR) is supported, but it also depends upon the bank whether they provides it or not. If you are existing Yodlee customer, you can send a request to Yodlee Support team to get your doubts clarified. BTW, the API should be used- getItemSummariesForSite or getItemSummaryForItem1( if you are looking for further details, pass correct Data Extents, while making request).

Related

Self-Service booking flow including payment

I'm checking the self-service API for flight booking. I got the process working ok: Flight Offers Search -> Flight Offers Price -> Flight Create Orders.
I've tried it and I got all the responses OK. I also understand I need to meet a few requirements to do the actual bookings in production.
What I don't understand is:
1) Where do I enter the payment information?
2) If the traveler is paying through credit card, is there an online form that is secure and compliant so I don't actually store the traveler's credit card info?
Thanks!
In Self-Service the booking works with a consolidator (an entity that will manage the ticketing with the airlines for you). You don't need to pass the payment method in the API call as you will have a contract with the consolidator and have this information directly provided to it. We are about to publish more documentation about it, as of today we open production only to some pilots, if you are interested you can contact us at developers#amadeus.com.
This part needs to be managed on your side, you will be the one handling the payment and the secure process to do it.

Can I use API to Automate Posting Tracking Numbers to orders?

We ship using FEDEX and UPS, and we never found a need to post the tracking number to the payment record, however, recently a customer did a charge-back and the claim was that the order was not shipped even though it was. The tracking number was not entered into paypal, but we do have a tracking number for this order. Do we need to manually enter every tracking number into Paypal, or do we have a chance to enter it after a chargeback attempt has been made?
PayPal's standard API does not provide a field for tracking numbers in their order details, so there is no way to automatically send PayPal this information for all orders.
Their API supports disputes, so it could be possible, however it looks like it could be very messy. The workflow would look like this:
Use PayPal's Customer Disputes API to GET all disputes with a dispute_state of REQUIRED_ACTION and reason of MERCHANDISE_OR_SERVICE_NOT_RECEIVED. Save the Order ID
Cross reference the Order ID with your order management software's API to get a tracking number. If the tracking number exists,
Use PayPal's Customer Disputes API to escalate the dispute to a claim and save the returned claim API endpoint.
The documentation gets a little fuzzy here and may require some contact ith PayPal's support team, but it looks like you should be able to POST evidence to the claim with PROOF_OF_FULFILLMENT, which includes tracking_number and carrier_name.
Unless you are processing a high volume of these missing order claims it probably won't make sense to go through all this legwork. If it truly is taking a lot of time and energy for you or your staff to handle this specific type of PayPal dispute then maybe it would be worthwhile. I might also suggest in this case to start toggling the "signature required" settings for your shipping partners.

Tracking transaction data from credit card, any API?

I am required to create an application which collects transaction details of bank accounts, there are APIs like
Plaid
Yodlee
Geezeo
But these APIs make use of the clients username and password for retrieving the transaction data, but in my case I need to do so using only the credit card number.
Can it even be done?
Is there any other APIs that provide this functionality?
I have researched about this issue a lot but still can't seem to find any APIs that suits the requirement. Any help is appreciated, Thank you.
I just answered essentially this question for another user (Serizawa Sanjay), here is my response below:
"
I have worked for Credit Unions that have experience with all these types of APIs. The Geezeo and the Yodlee API will not allow you to do what you want since that would violate the privacy on the card and the card issuers will not allow someone outside of the flow of approvals to get to that data. There are a few APIs that you can get by working with partners like FirstData to look for a certain type of transaction or vendor that comes across their system if it matches a certain card number, but you have to be a key partner with FirstData, not an easy task.
As far as aggregating transaction data from accounts like credit cards, bank accounts, auto loans, mortgages, investment accounts and the like, you really want to be using an API like MoneyDesktop. Yodlee is good as well, it just does not have the coverage, uptime, or quality of data that MoneyDesktop has. Geezeo's API just does not have the critical features that a MoneyDesktop or Yodlee API has. First Geezeo does not do its own aggregation and it only has one partner to do their agg for them. Yodlee is only one source, but if there is a broken connection, at least they can control fixing it. If a connection goes down with Geezeo, there is nothing that Geezeo can do to fix it but wait for their aggregation provider to fix it. If your business, bank or credit union can't afford for aggregation to go down (reputation risk), you need someone like Yodlee that controls their own aggregation, or someone like MoneyDesktop that has many aggregation providers and can route between them the second that one of their connections has problems. Also, Yodlee and MoneyDesktop both do their own data cleansing and aggregation, where Geezeo does not and has to rely on their aggregation provider. This is extremely problematic because as users editing and input to the system as to the transaction being data cleansed incorrectly or categorized incorrectly is not taken into account properly or optimally.
I have also heard that Intuit Data Services has a good API as well, but I have never had any experience with it.
Good luck!
"

variable monthly charges to users

I have a situation where I am to bill the site users monthly. But the invoice amount that is raised depends on the the leads that our site generates for his business. For example if the user gets 5 leads from my site and I charge him $10 per lead, at the end of month he will be charged $50. similarly leads might vary each month so will the amount.
Now I cant store his cc/ paypal credentials on my site for security reasons nor can I pre bill him or ask him to take credits and then use it. Please let me know the way to handle this situation. How can I handle this using paypal?
There are a few different ways to handle this, but I would recommend Preapproved Payments, which are part of the Adaptive Payments API.
With this method your users would create a profile with you (using the Preapproval API) when they first create their account on your site. That will give you a preapproval key that you can store with your user account. Then in the future when you need to bill them you can use the Pay API with the preapproval key to process funds immediately without further approval.
If you're working with PHP my class library for PayPal will make these calls very simple for you. You would just use the Preapproval.php template to setup the profiles for people, and then use PayWithOptions.php to process payments using the preapproval key(s) accordingly.
If you end up using it and need more help you can contact me directly for support.

Current PayPal Fees in web API?

Does anyone know if there is a publicly available PayPal resource that would allow me to calculate transaction fees in my Magento code?
For example, if someone buys something for $1.00, I'd like to know if $0.15 of that is a PayPal fee.
If there were a resource, like paypal.com/currentfees.xml or something that I could readout in my PHP code, I could that. Does it exist? I know there are different fees for different payment methods (e.g., AMEX) and fees could change at any time -> So it'd be good to have a dynamic way to calculate how much of Magento's order totals are really PayPal fees.
EDIT: To clarify, I'm not interested in charging customers more, just in knowing how much of my price is going to fees. For bookkeeping.
Thanks!
PayPal fees are not the same across accounts or even by transaction; there are different fees for cross-border transactions, PayPal Here transactions, large-merchant discounts, et cetera.
Have a look at https://www.paypal.com/webapps/mpp/paypal-fees for more detail.
So no, unfortunately you can't pull a resource to find the current fee.
However, PayPal does return the fees paid for each transaction in the API response.
For example, if you're integrated with PayPal Express Checkout, the DoExpressCheckoutPayment API (doc) is used to finalize a transaction. This API call returns a 'PAYMENTINFO_0_FEEAMT' parameter which contains the total fee amount paid for the transaction.
Should you wish to retrieve this information after the transaction has been completed; PayPal also offers the GetTransactionDetails API call (doc). This API call also returns 'FEEAMT' as a parameter.
Simply submit the TRANSACTIONID and read out the FEEAMT.
Note: Fees are only calculated on completed transactions. You won't get a FEEAMT back for any order or authorization-ID's (e.g. those starting with O-xxxxxxxx).