Paypal Pro

Anyone using it yet?

[HRoth]

I have read over their documentation, and I think it might work for me. I know some people have had bitter experiences with Paypal. I've had about 1000 transactions with them and only one chargeback. That one Paypal settled in my favor. They didn't freeze my account or anything, just called the money back until it was settled. I really hate paying as much as I am paying for the payment gateway, the processor, and my merchant account. So has anyone been using this? I can't find much in terms of online reviews because it is too new.

[sun818]

I've been using the Virtual Terminal part of the Website Payment Pro for about two weeks now. I'm definitely happier with the processing rates especially on merchant account providers call "non-qualified" transactions (i.e. government, corporate, international, or cash rebate cards). My particular issue with the service is that it will decline more charges than the ones I send through AuthorizeNet. Maybe Wells Fargo is being more strict about what transactions it will approve, but I can not make sense of some of the domestic transactions that have an AVS code of "Y" (Address matches, 5-digit Zip code matches) not being approved. The approval/decline process also seems a bit slow compared to AuthorizeNet.

Even with all that, I would like to use a shopping cart integrated with their Express Checkout/Direct Payment API. Hard to find one that does it quite right, but I'll keep looking! :)

[HRoth]

You mean if AVS returns no match, it declines it and you can't override that? Do you use automatic capture or do you do authorization and capture by hand?

[HRoth]

I decided to call and ask Paypal about this issue of declines, since I get a lot of stuff that gets no match on the AVS - for instance, pretty much everyone who uses a PO box, lots of people who have a street name that's a number, anybody who can't remember their zipcode properly, etc. Turns out that in fact Paypal declines any transaction that does not match any item on the AVS. You can't opt to approve the transaction yourself like you can with Authorizenet. Not good. A penny-wise and pound foolish policy.

[vlink]

I'd like to know if anyone has had any experience with Payments Pro also, as I'm seriously considering going with it. Comments please?

[volatilegx]

Hi vlink and welcome to WebmasterWorld :)

I've signed up for Paypal Pro. The features look great. HOWEVER

Getting my custom written shopping cart integrated is a FREAKING NIGHTMARE!

I've done payment gateway APIs before, and I'm proficient in Perl, PHP, MySQL, etc., but this one takes the cake for being difficult. I'm running into roadblocks at every turn and support is somewhat lacking.

The documentation is very patchy, leaves important things out, is lacking in examples, and requires a very high degree of experience/knowledge to understand.

Code samples provided actually require SuperUser shell access to install.

I've never encountered an API which was more difficult to install.

[volatilegx]

On a happy note, I was contacted by a Paypal rep and they are working with me to hopefully devise a more user-friendly method to integrate their API.

[volatilegx]

Well, I'm going to expand on my experience with integrating my custom PHP shopping cart with Paypal Pro. At first, I was having some serious problems:

1) The "SDK" Paypal provides is difficult to install. The SDK is a collection of PHP scripts which is meant to generate code for you to use to integrate your cart. It requires superuser shell access to install. You must already have Pear installed on your server to use it. The sheer amount of code contained within the SDK is daunting. I recall a 9 meg upload (maybe I'm off a meg in either direction).

2) The documentation is very long on wordcount and short on useful examples. It's tough to find pertinent URLs (such as the one you post test data to). Also, the documentation is split into at least four PDF manuals, one of which is over 110 pages long.

3) The API uses SOAP, which in itself isn't my favored method of communicating, but I can overlook that. However, the documentation didn't give any good examples of the actual XML SOAP requests.

4) You have to download a security certificate, which must be converted into another format using a third party's encryption software (openssl is what I used). Now, for testing purposes, the certificate doesn't need to be encrypted, but this isn't explained in the documentation so I futzed around for quite awhile before discovering this.

OK -- those are my complaints. Here's my kudos:

I've been working with the Paypal Product Manager to straighten out my misconceptions, etc. and he has been very helpful in answering my questions and pointing me in the right direction. He's also seemed willing to update documentation and make other changes to make things easier for the average customer to integrate their API.

As to the issues I had, here's how I resolved most of them:

1) Definitely visit the site: [paypaltech.com...]

The above page gives actual PHP code, along with XML SOAP examples which you can use to easily build a working integration solution.

Using the examples on that site, along with several tweaks of my own, I managed to build a working integration solution without using the PayPal-provided SDK.

2) Although the documentation is "wordy", the actual API reference is pretty good. They explain the type (field) names pretty well, and even tell you what type of data they should contain, down to the number of bytes allowed.

3) They have a full test environment that mimic's PayPal's actual environment. You can do any kind of transaction -- charges, refunds, etc. Very extensive and very handy.

I intend to post working examples of PHP code (sanitized to remove account names, etc.) on my own website at a later date.

Anyway, I hereby retract my earlier statement that Paypal Pro integration is a "freaking nightmare". Maybe it needs a little work to make it easier for the average website owner to get going, but the potential is there for a really flexible payment processing system -- and PayPal's merchant rates are pretty good.

Dan

[vlink]

Thanks for sharing your experience, volatile, all good to know.

[davidhorn01]

Volatilegx - thanks for your useful comments on this post.

I've been playing with the code here: [paypaltech.com...] and am only getting so far with it - I was wondering if you could help.

In ec1.php, if I reference the paypaltech.com site for ec2.php, then it works fine ... if I use my own ec2.php then I end up in sandbox with 'Authorization failed - This transaction is invalid.' I can't see any real differences in the ec2.TXT that is provided and the ec2.php that I created from it ... and I don't really know where I'm going wrong. Any ideas?

Thanks again,

David

[volatilegx]

My first thoughts are these:

1) Are you logged in to the sandbox with the account that is receiving the payment? If you're not, you'll get the message you reported.

2) Did you download the API security certificate from the sandbox account that is receiving the payment. Did you put the certificate on your website and refer to it in ec1.php?

3) Did you use the correct password in the SOAP request?

[davidhorn01]

Hello, and thanks for your reply,

I'm logged in to sandbox with my own account - I'm doing this work on behalf of a client who has their own PayPal account, so I'm using their PayPal API information, but my sandbox ... but even if I set it up in a live environment, going straight to PayPal I get the same error?

The API security certificate is downloaded from the clients live PayPal account. It's in the right place on the server.

The password I'm sending in SOAP is the correct one for the clients API - yes.

Anyway, so It might be the first one, but surely, if any of these were the case my ec1.php wouldn't work with the paypaltech.com ec2.php, would it?

Thanks again for your help,

David

[CernyM]

Are they still having issues declining too many transactions?

[jwolthuis]

I've been using PayPal Website Payments Pro since September 9 (4 months). Here are my numbers:

Successful transactions: 1013
Failed Transactions: 157

I've only counted unique customerID's in the failures, to eliminate the customer who repeatedly fails to complete one order.

Included in the 'Failed Transaction' count are those customers who eventually placed a successful transaction.

The #1 reason for a failure was AVS mismatch. In second place was invalid CVV code.

[sun818]

> AVS mismatch

This would include every gift credit card that's out there.

[jwolthuis]

> This would include every gift credit card that's out there.

Right, good point!

[grobe]

jwolthuis:
So why are you still using them with this many declined orders? Have you looked at the declined orders in detail? Do they look like legitimate buyers? Are you running any of the declined orders through alternative processors?

Anyone else have any figures?

[jwolthuis]

grobe: I don't consider it excessive. I'd like to see other people's data, but I think my numbers are probably typical. There are a lot of over-extended credit limits out there, as well as billing address jibberish (see further comments below).

I don't see my number of 'failed transactions' as a black-eye against PayPal. I fact, I'm very pleased with Website Payments Pro, having switched in September from Authorize.Net. I don't see 'unexplained' authorization failures.

PayPal doesn't approve or decline a transaction. They are simply a gateway. The approval is left up to the bank, AmEx or Discover. PayPal requires AVS, which is a high-bar to get over for a lot of customers.

Given the jibberish that people type in for billing and shipping addresses, I sometimes wonder how they find their way home from work every day.

Most of the 'failed trasactions' are due to incorrect billing addresses (AVS failure). These customers are able to place an order once they type in where they actually live.

[CernyM]

I got the impression that PayPal rejected more from AVS issues than, say, Authorize.net might. If this isn't the case, its probably not that much an issue.

Requiring CVV might be though. We turned CVV off - we lose more sales because customers cannot figure out what it is than we could possibly save via reduced chargeback. (Our chargeback rate is under 0.05%).

Our transaction approved rate is around 94%. The "real" decline rate (once people fix their AVS errors) is probably much lower - 2-3% feels about right.

[jwolthuis]

The data in my first post might be misleading.

I joined my 'failed transactions' with my 'orders', and found that 116 of those 'failed transactions' proceeded to place an order that same day.

In other words, whatever caused the initial decline, the customer was able to fix and get approved.

This works out to an actual decline rate of about 4%.

[volatilegx]

In response to message #12, above:

> The API security certificate is downloaded from the clients live PayPal account. It's in the right place on the server.

Make sure the security certificate is downloaded from the Sandbox if you are accessing the sandbox API. Also, the sandbox certificate doesn't need to be converted to a .p12 file. It's fine as a text file. It would be nice if this was mentioned in the docs.

[sun818]

> I got the impression that PayPal rejected more from
> AVS issues than, say, Authorize.net might.

The issue is that AuthorizeNet provides more flexibility. As the example I provided above with Gift Credit Cards - the billing address is some bank address the cardholder would never know. If s/he tried to buy something through Paypal Gateway, the transaction would be rejected and that's that.

While the same could happen with AuthorizeNet, you as the merchant, can tweak your settings to accept Gift Card (e.g. accept AVS rejects). I just like having the flexibility. It doesn't make sense for every business, but it does make sense for mine since my average ticket is about $40.

[pp_rb]

As the example I provided above with Gift Credit Cards - the billing address is some bank address the cardholder would never know.

Not in all cases - I've purchased one-time-use Visa cards that allowed the billing address to be configured online. It was buried in the Terms & Conditions pamphlet included with the card, but the bank teller made a point of explaining how it would need to be registered & configured if I planned to use it online. Of course, I don't know if all such gift cards (or bank tellers) are as accomodating.

[sun818]

> Not in all cases

I do apologize for the blanket statement. Aside from those customers that take the time to figure out how to configure their billing address for a gift card that they will use online, gift cards would be rejected by the Paypal Pro gateway for AVS issues.

My point: Give us the flexibility to manage risk for each Paypal Pro account.

[sreenushetty]

volatilegx,

Thank you for your efforts for making paypal express check out code available.

My background:
Good understanding and working with PHP
New to API and SOAP

My Query:
How can I intergrate express checkout option in to my clients website?

Thanks,
Sreenu