Looking at the Balanced docs, it appears that debiting a card is the same as debiting a bank account. Just supply the proper source_uri.
But having some experience in the ACH world, I'm know it is traditionally possible for my ACH debit to be returned several days later.
How does Balanced handle this? When Balanced returns a successful response to my attempt to create a Debit, does Balanced have some mechanism to ensure that the ACH debit will be successful? Or is there some mechanism to be notified of a failure?
Absolutely, ACH debits (and credits!) can fail. And due to the asynchronous nature of the ACH network, they can sometimes fail many days after their creation. Take a look at the 'Payment status' section of https://www.balancedpayments.com/ach-debits for some information.
Balanced provides webhooks/callbacks on transaction state updates, so users can always be made aware of the most current state of a transaction. The dashboard will also reflect the most current information, of course, as well as the API's response to a GET request.
Related
(Not sure if this is the right place to ask. Please point out other forums if that's not the case).
I'm based in Europe, and I've set up an invoicing system for a client of ours which uses a tokenization system provided by his bank, as part of the bank's secure payment services. (In other words, this is not any of the big american services like Paypal, Braintree, Stripe...).
The problem is that, in order to input a credit card into the system, this
bank needs to charge an initial amount of 0.01 € to it... and when it does that, the credit card owner gets a text message code to approve that charge, without which the card number cannot be introduced. This is not practical for my client, for a variety of reasons. We have asked the bank, and they say that this is all dependant on the card issuing bank, and they can't do anything about it.
My question is...: what do we do to avoid this? From what I remember, other tokenization system I've used also had an initial 0.01 cent charge, and yet I never received any text messages from them (this was a few years ago, admittedly, before 2FA became widespread). How do the big payment processors (Authorize.net, Stripe, etc.) manage to store credit cards without making an initial charge and triggering two-factor authentication in the process?
Thanks.
The reason behind performing an authorisation (not a charge) is to ensure the card is valid before it is stored.
However, the $0.01 authorisation is now considered 'the old way' of doing this. Most card acquirers now allow an authorisation value of $0.00 to be used solely to check the card is valid. This shouldn't trigger any 2FA where it is supported.
Obviously though, this is payment processor dependant on whether they support this 'new' functionality. A small number are still stuck in their ways
The other alternative is just to process the full transaction value. It shouldn't be necessary to submit the card for tokenisation before using it, though admittedly this depends on your business use case.
How do people deal with the situation of bounced checks when getting Yodlee transactions through the Aggregation API?
Our app only retrieves posted transactions and it has led to an issue.
Most banks seem to balance the bounced check situation by providing posted transactions for both the initial check disbursement (negative amount) and for the bounced check (positive amount). Bank of America, however only posts the positive amount transaction - (the one the increases the balance of the consumer's bank account) - the original transaction never gets past the pending stage. and since the original transaction (the check) is never posted it results in an incorrect increase in balance on the consumer side.
Any thoughts?
If you are customer of Yodlee, then you can reach out to Yodlee's support team and raise your issue with details like BankName, SiteId,memSiteAccId and cobrandId. Yodlee's data team will look into it and would be able to help you out.
We use DoExpressCheckoutPayment API function to do payment authorization. The DoExpressCheckoutPayment response has ReceiptID field, which is empty if the payment was funded from a Paypal account or is filled if the payment was by credit card. Is the ReceiptID field also filled if the payment was by debit card? If so, how can we distinguish a receipt is that is for credit card from a receipt that is for debit card? Or is there some other way to distinguish debit card payments? We get a lot of fraudulent transactions with stolen credit cards. Since credit card payments are likely fraudulent and debit card payments are likely good, we would like to have a way to know whether a payment was from credit card or debit card to help us decide whether to accept the transaction or not.
Thanks
No, PayPal does not tell you how one of their accountholders is funding a payment. That information will not be available to you.
If you will permit me to editorialize for a minute, though:
That's a Good Thing, because the reality is much more complex than debit vs. credi. You don't want to try to second-guess all of these possibilities. Payments might be partially funded from multiple sources; have conditional aka backup funding; use "cards" that are neither the debit nor credit networks you are familiar with (e.g. hybrids like China Union Pay, virtual debit cards backed by who-knows-what, ...); various bank draft networks/mechanisms; PayPal lines of credit; etc. In general, PayPal is doing a LOT of sophisticated things to detect fraud and they deliver very low fraud rates for accountholder payments.
Also: if you are processing an accountholder payment (rather than a direct credit card payment), PayPal's seller protection policies replace whatever protections (usually not much!) you would receive from card networks for Card Not Present transactions. These protections do not depend upon what funding the accountholder uses and may be very useful to you. I recommend you read the policies and determine if you can align your business so that most or all of your sales can qualify for these protections.
If your usage cannot be eligible for PayPal Seller Protections, though, then while PayPal still runs their fraud detection they have a pretty limited set of facilities for you to layer on added fraud detection of your own. They will give you a limited amount of information about the accountholder, but as I noted above this does NOT normally include the account's funding source(s).
We have implemented the Card Security Code check when using credit cards.
This produced a value on the attribute security_code_check of passed, failed, unknown.
Balanced state "It's strongly recommended you do not process transactions with cards that fail this check."
However the security code check is not done until an authenticated operation is performed against it the card.
So by the time the check is done we have attempted to process the card. So how do we follow the advice not to use it?
Creating a hold on the Card to do this is wrong and unnecessary. Doing so ties up a customer's available funds and causes confusion.
An authenticated request claims a tokenized funding instrument to a marketplace, which triggers Card verification at the same time. This is discussed in several places in the documentation, chiefly in https://docs.balancedpayments.com/1.1/guides/balanced-js. If you wish to check the CVV result before attempting to charge the card, you should perform an authenticated request on the Card such as a GET, or even associate the Card to a Customer resource. This will initiate the Card verification and provide the ability for you to check the verification results before attempting to charge the Card. Immediately attempting to debit the Card does not provide such an opportunity.
"However the security code check is not done until an authenticated operation is performed against it the card."
An authenticated operation includes performing a GET on the card token returned by balanced.js, which is required to store the card anyway. It is not required to debit the card first.
You would create a hold on the card first. If the CSC succeeds, capture the hold. If it fails, void the hold.
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).