PayPal totally screwed us on this one by cancelling support for all older versions of the DLL (the one we have is less than a year old) without any notification to us via email. We're testing the newer DLL now to resolve the issue.

Paypal strikes again. I am so impressed with them! Sign me up before I change my mind.

Well... just seems to me if PP is going to ask us to use their services, it's up to THEM to make our life easier, not the other way around. We're the ones paying fees to THEM so we're their clients, right? For second there it was looking like we work for them.

Somebody's going to get it right, do it cheaper and run them out of business. So far, Google is on the right track, but if Microsoft builds a PP style gateway into Vista, look out. It's such a good idea, I can't be the first to think of this....

I do plenty of on-line banking without PayPal's help.....

Gates and Co will screw it up... nevermind.

I'm a bit confused. I have Payflow Pro customers using my payflow pro processor that are not reporting any issues. There may be newer versions of the payment dll but I don't see it breaking earlier versions.

Also, it might be a good idea to subscribe to their PayPal developer feed: feed://www.pdncommunity.com/rss/board?board.id=payflowstatus

This will allow you to stay on top of things a bit better.

Also, PayFlow Pro is a product of Verisign. It's been a COM application forever and it wasn't until PayPal bought it from Verisign that they actually started to improve it and bring it into this century. I know some of the tech team from Verisign came over with it so perhaps that is part of the problem. I know someone on the inside (which I am not at liberty to share) and they have informed me that previous versions should still work but always suggest staying up to date.

Oh and as far as MS, Vista and Gateways. That makes zero sense and the last thing we need is MS integrating anything regarding payments and credit cards. They couldn't even get Vista right. If it wasn't for .NET I wouldn't even own a Windows PC and every day I find myself using more and more technologies for web development not born of MS.

How do you know that? Maybe they will get it right this time :)


Regards,

Corneliu.

To boil this down... BVC is sold to single licence holders, small store owners. Like all other platforms in it's price bracket, BVC touts integration with most payment processors, PP included. (There's even a check-box for it in admin) This is a sales pitch, a promise, an 'ease of use' premise upon which a small store owner should depend when he pays his money and commits to spending 100's of hours building his store.

If hiring a developer is a requirement to get certain payment gateways working - it's being kept a secret.

I set up Authorize.net on my previousstore6 and on my BVC store. 10 minutes, tops. Has anyone spent 10 minutes integrating PP? As I said, if they want me fees, they can make it easier for me. They're loss, not mine. I'm sure they don't miss me.

As a small business owner I don't like this idea that I need to learn how to install dll patches and spend hours testing and fiddling and pestering BV's staff and/or hire a developer or buy a $XXX.00 plug-in (more fiddling) just to make PP work.

Andy, awesome trick, thanks! I just redirected the assembly version by placing this after the connection strings section in the web.config:


No more application errors complaining about the new version. I was able to test an authorization and capture successfully without errors in TEST mode using the new DLL, but I'm getting this payment error in LIVE mode:



Not sure why it works in TEST and not LIVE. So no luck yet.

Marcus, I hope this helps. To sum it up so far:
1. The SP2 store was originally using v4.1.0.0 of Payflow_dotNet.dll, which wasn't included in the BVC installation (I had to get it from CodeSine).
2. The upgrade to SP3.2+hotfixes suddenly began referencing an older Payflow DLL (4.0.2.0, which also wasn't included in the SP3 upgrade files).
3. The required 4.0.2.0 or something in SP3.2+hotfixes broke the ability to authorize and capture. I'm uncomfortable with rolling anything back as so many updates have been done.
4. Redirecting the assembly version to the latest 4.3.0.0 downloaded from the Payflow SDK works, but doesn't fix the issue. Nice to have the latest, I guess.
5. Seems the problem is in the payment code on BVC5's side somewhere after SP3?

Could this be as simple as a currency code typo in the SP3+ main payment DLL?

Once again, I'm in debt to Tim and Andy. Thank you guys so much; this has been a hell of a week and I'm so far behind because of this shit.

Tim and I have been testing all afternoon and he whipped up a separate payment plugin for me this afternoon that works with Payflow_dotNet.dll and overrides the Payflow code in the BVC5 payment dll. So far, orders are finally being authorized when placed. He's basically the man.

My only source of relief has been orders that customers have selected the PayPal option for have apparently been processing just fine. BVC5 updates one thing and breaks another well too often to be this far out of beta. I'm so sorry, but it's too obvious to be personal opinion, unlike certain diatribes in this thread. That fine line adjacent to tapped patience is fast approaching.

I love the BV crew, but you'll never accuse me of being a blind fanboy. I'll be rocking in the corner in the fetal position if anyone needs me.

Cliff,

Try going to Options->Payment->Credit Card->BV Payflow Pro and editing your settings. See what currency code is selected? Make sure it's US Dollars and hit "save."

Marcus, perhaps try Tim's fix above and reference the new DLL (v4.30), unless there's something deeper in 3.2 that may have created the problem. Those were in the files he ended up sending me yesterday and it seems to be working so far.