asking this after searching without specific topic/answer.
I am gonna implement paypal express checkout to deal with customers paying by credit card. They request the support of level 2 credit card processing to upload such as customer id. Failing to find right answer in paypal doc or here, I only find ( Submitting Purchasing Card Level 2 and 3 Transactions ) in paypal doc, which I think is not for credit card.( https://developer.paypal.com/docs/classic/payflow/integration-guide/#submitting-purchasing-card-level-2-and-3-transactions )
Does anybody can help with piece of information/doc ? Very appreciated!
For the most part, no. PayPal Express Checkout does support some level 2 and level 3 data -- for example, tax amount, shipping ZIP code, line item details, etc.; however, this data is only recorded internally at PayPal and is not passed on to the card issuer.
If you need to submit this data, the Payflow gateway would be the way to go. (The documents that you found on submitting level 2/level 3 data are in regards to the Payflow gateway.) Payflow is a "bring your own bank" product, meaning that you would need to have a processing relationship with a third-party processor first (such as First Data, Chase Paymentech, TSYS, etc.), as well as your own IMA, and ensure that they support level 2/level 3 data first before signing up.
Related
I am setting up the Paypal integration for a Clients website. He has a page where users can buy stuff that others users sell and he wants the buyers to pay using Paypal, he also wants the payment to be charged a fee, so that a percentage of the payment goes to the website owner and the remainder goes to the seller. For example:
Tom sells shirts at $20 each and i want to buy two, so i would pay $40 plus the 3% of the transaction, that would sum up to $41.2, $40 would go to Tom and $1.2 to the page owner.
How can i do this using Paypal? I have been reading a lot Smart Payments Button describes how to set a payment but the funds go to a single person, i need to set a chained payment, split payment or something alike and their docs seem very fuzzy.
Any help is appreciated.
Thanks!
platform_fees , documented here , is the analogue to chained payments. However, it is only available to PayPal partners -- i.e., probably not your client.
For separate transaction payments to more than one receiver account, there is multi-seller payments.
After completing the Paypal Integration and after tears and pain i can tell that i couldn't use platform_fees.
The implementation is complete and working but i wrote to customer support and to dev support and they just don't want you to use platform_fees so nothing will work along that path.
The solution they provide and the one they want you to use is getting all the money on your account and then splitting it using Payouts to all the clients.
Really bad solution imo but its convenient for them because they charge more transactions instead of allowing you to do everything on a single transaction.
I understand there are a number of account aggregators out there which allow businesses to get access to customers's transaction data (Plaid, Yodlee, Intuit Customer Account API, open to others...). I'd like to know which ones DO or DON'T also allow for:
Determining the DUE-DATE of a customer's credit card balance.
Making PAYMENTS across accounts and parties.
Response from Yodlee
1) Determining the DUE-DATE of a customer's credit card balance
Yes , Yodlee do provide credit card bill due-date though their API.
2) Making PAYMENTS across accounts and parties.
Yodlee does have a Bill-Pay product but it's not available to API customers as of today.
I've been working with a loan repayment API and ran into this issue as well with Plaid. For US banks only, it seems that there are three items you need for this system:
The bill due date (and amount) for the credit card
The banking information. At a minimum, a user's routing and account number (which Plaid can provide) and the credit card's banking information (their routing and account number for direct payments).
An ACH processor or US bank that will let you upload a NACHA file. This is the step that actually moves the money from one account to the other. Expect lots of compliance paperwork from the partner that you use.
It's a complicated world when you try to pay on behalf of a user. Outside of programming, get a good lawyer who knows bank law!
Response from Plaid (as of 9/22/2014): No/Not yet and No
"1) Within a customer's credit information, does Plaid provide their credit card bill due-date? what would be the appropriate call for that?
Currently no, but it's something we may add in the future.
2) Does Plaid offer anything by way of making payments or money transfers across accounts? (I'm assuming 'no,' but just want to confirm)
We do not, however we can help with the authorization of accounts for ACH & Wire transfers. Feel free to reach out directly for more information."
Is there a way to find the transaction type using PayPal's API's? I have reviewed the NVP docs a few times, but it appears the NVP documentation is not complete and I can't figure out how to find what the funding source was.
This is for an ecommerce website and we are wanting to find out if more fraudulent purchases occur with Credit Cards or funds from within a PayPal account. We assume credit card, but we are trying to lessen the number of checks we have to do on all purchases to verify they are legitimate.
Have you looked at the Fraud Management Filters? here..
Fraud Management
I'm not sure you can tell from the values returned if it was a credit card or paypal account, i.e. I'm not sure if the fraud filters are applicable for a paypal account payment?
There seems to be a lot more "effort" having the filters ON but you are reducing your exposure to fraud and could have the filter on for 10% of transactions instead of them all.
Problem: I've implemented "partial authorizations" (pg 72) but whenever I try to run a transaction that could use it, the result is a decline.
Setup: I'm handling transactions with the API with PayPal Payment Pro Payflow Edition (aka, PayFlow Pro Gateway & PayPal Merchant Account).
Cards use in Transaction: Visa Gift Card & American Express Gift Card. This feature was made for gift cards and other prepaid products. Gift Cards are specifically cited in PayPal's documentation example.
Transaction Logs:
Here is the log for a declined partial authorization. The original amount requested is $25.00, even though this visa gift card only had $2.00 on it. I should have received a response with an approved amount for $2.00. Instead I got a decline.
-> PARTIALAUTH:Y TENDER:C ACCT:**** VERBOSITY:HIGH TRXTYPE:A EXPDATE:0618 AMT:25.00
<- RESULT:12 CARDTYPE:0 PROCAVS:G IAVS:N PROCCVV2:I EXPDATE:0618 RESPMSG:Declined: 15005-This transaction cannot be processed. LASTNAME:NotProvided ACCT:**** AMT:25.00 PNREF:************ AVSZIP:X AVSADDR:X HOSTCODE:15005 TRANSTIME:2012-12-14 12:43:04 CVV2MATCH:X
For comparison, when I run the same card for an amount that is less than what's on the card, it goes through no problem:
-> TENDER:C VERBOSITY:HIGH ACCT:**** AMT:.11 TRXTYPE:A EXPDATE:0618 PARTIALAUTH:Y
<- AMT:0.11 AVSZIP:X PPREF:***************** ACCT:**** AUTHCODE:111111 TRANSTIME:2012-12-14 12:41:46 LASTNAME:NotProvided IAVS:N PROCAVS:G RESPMSG:Approved PNREF:************ RESULT:0 EXPDATE:0618 PROCCVV2:I CARDTYPE:0 AVSADDR:X CVV2MATCH:X CORRELATIONID:*************
-> TENDER:C ORIGID:************ TRXTYPE:D
<- RESULT:0 PENDINGREASON:completed PNREF:************ FEEAMT:0.11 PAYMENTTYPE:instant RESPMSG:Approved PPREF:************ CORRELATIONID:*************
I believe the API calls should be and in fact are the same in both cases. The point of Partial Authorizations is that you don't know when you need it, so if you want it, it should be enabled for all transactions -- meaning you always append the two extra parameters of VERBOSITY=HIGH and and PARTIALAUTH=Y.
Any ideas why this isn't working. The feature is very important to my application and is one of the main reasons I'm using PayPal.
I hope I'm missing something simple, like a setting in manager.paypal.com.
From what I can see you're doing everything correctly. When something like this happens the only thing you can do is contact PayPal directly.
You can do so via www.paypal.com/mts or if you login to your PayPal account and go into the contact by phone section you should see a separate phone number for tech support directly.
I would recommend submitting a ticket to MTS and then also calling, but when you call, refer them to your ticket. They're going to want you to post one anyway, but if that's all you do it probably won't get answered for awhile, unfortunately. I've had good luck catching them on the phone, though, and can get things done much more quickly that way.
The only thing I can think of that might be an issue here is that you're using the PayFlow gateway with PayPal as your merchant. While the PayFlow gateway supports this, PayPal may not. It may only work if you're using a 3rd party merchant account on the PayFlow gateway.
That's something they will need to confirm or deny as I haven't specifically tested this myself, but again, I don't see that you're doing anything incorrectly.
I have a bit of experience setting up online payment systems that accept credit card numbers and then pass them over to a gateway for a one time payment.
However, I now need to setup a system that can handle automatic recurring billing - where a user provides their credit card number and is automatically billed on a monthly basis from that point forward.
I am wondering what the best way to approach something like this is? (I notice that Paypal Payflow Pro does have a recurring billing feature, but I am a bit unclear on how it works.)
Any advice on the best method / service / gateway for implementing recurring billing? If possible, I would greatly prefer to avoid keeping a local record of credit card numbers for repeat processing.
Thanks (in advance) for your help.
There's a midpoint between building your own recurring billing and Auth.net's ARB or PayPal's recurring billing (both of which have their disadvantages). There are a number of providers that handle all the details and complexities of recurring billing, and simply report the charges to your payment gateway for processing at the interval you determine.
The most critical piece to look at is which services to credit card tokenization and support credit card data portability - this will ensure that your customer data isn't locked in with a billing provider and that you can take it with you if you choose another provider in the future. This also means that these providers store the customer credit card data for you, so you can greatly reduce your PCI compliance.
Take a look at Recurly (Disclaimer: I manage their customer and technical support) and Braintree. Both services will handle your recurring billing, credit card tokenization, and support credit card data portability.
Recurring billing is easy to handle and offload to a third party if your recurring amount is constant (e.g. the amount a user pays never changes in amount or frequency). Services like Authorize.Net's Automated Recurring Billing (ARB) and Paypal Payflow Pro recurring billing allow you to have those companies handle the actual recurring payments which means you don't have to store credit card information on your servers or even do anything once the subscription is created through their APIs.
If your subscriptions will vary in terms of cost or frequency, you'll need to use a service like Authorize.Net's Customer Information Manager (CIM) to create payment profiles for your customers. Basically you're storing credit card information on Authorize.Net's servers and whenever you want to make a subscription payment you tell Authorize.Net to charge the amount due to that payment profile. The drawback to this is you essentially have to build your own subscription system.
You usually find the recurring billing features in middleware gateways like Payflow Pro. In that case, it is invoked by a variation of the API you use for card processing. You usually set up the time span between billings and they perform the billing. You usually then reconcile the billing with the report that your processor sends you each month. In some cases, the payment gateway will post a notification to you that the billing was performed. You still have to reconcile the payments with the processor report because sometimes the notifications fail.
Canceling the recurring billing is also another API call.
If your gateway doesn't have the recurring feature, you obviously have to set up the billing yourself. This of course leads to storing card info and so forth. In this case, you usually tell the processor that it is a recurring transaction (which the gateway will do for you) so you get a discount on the transaction fees.
First, let apend the statement above "...tell the processor that it is a recurring transaction ...so you get a discount on the transaction fees". The true cost of credit card processing is a percentage fee and a per item fee based on the type of card presented ( and some other factors I won't delve into here.) The point being, on a wholesale price plan, the price would be the same regardless of whether it was recurring or not because there are no special rates for 'recurring' in interchange. But I digress.
"Any advice on the best method / service / gateway for implementing recurring billing?"
Don't take on storing credit card data no matter what. You can't afford the liability.
The right choice depends on several factors.
As to credit card portability, has anyone gone to Wells Fargo/ First Data and gotten their data out? (Braintree ISO/MSP). I guarantee it won't be pretty no matter what so I would focus on the right long term solution, rather than the exit strategy, though it will certainly weigh in.
Here's questions that need to be answered:
How many transactions per month? For very low volume, maybe a few hundred, pick paypal pro. It's easy to get into/ out of.
Are people more likely to pay with consumer cards or business credit cards? Interchange optimization is important if business cards. (CenPOS automatically optimizes the transaction for lowest interchange qualification, paypal and authorize.net do not)
What methods does my client accept payments? self pay on internet only? Phone orders? Mobile payments (special events or retail)? Choose a gateway that fits all their needs.
Do you need to charge on specific days- ie the 1st and 15th? Or any time? If on specific days, how will you prorate? Check the answer against the gateway flexibility.
What happens when a card expires?
What happens when a transaction is declined?
Who will need to see the payment data for customer service? How will they access it?
Determine your needs, then figure out which ones meet them.
For the record, CenPOS is the most robust solution, but may require more steps to integrate since they are newer to ecommerce.
Disclaimer: I've been a business user of paypal and authorize.net for probably a decade and more recently CenPOS. I'm also an authorize.net reseller, and CenPOS direct agent.
Just a heads-up about Payflow Gateway's Recurring Billing:
Their Instant Payment Notifications (IPN) is a fantastic feature, but only applies to their legacy APIs. For the time being, THE ONLY WAY to be notified by PayPal of a successful (recurring) billing transaction, is by inquiry. You will need to maintain a schedule to inquire, and send an individual inquiry for each, scheduled recurring billing transaction, one at a time. PayPal will not notify you if, for example:
A transaction is approaching
A transaction has occurred
This transaction was successful
This transaction resulted in fault
A credit card is approaching expiration
A dispute occurred
... and so on.
In my opinion, this renders their service useless.