confused re adding CreditCard Payment to our VFP9 app

[OldxBaser]

I don't want to get in trouble in this forum for posting this because there seems to already be quite a few references to this topic, but many are old.

We have been designing / distributing a very large VFP system for many years now (about 2,500 clients - mostly in Canada).
We want to add a CreditCard Payment feature to our system.
Our client base would like to take CreditCard payments over the phone from their clients.

I don't know where to start. I have researched this a lot lately, but find myself going in circles.
From what I see so far, it appears I will need something like Authorize.net to get started.
I see other references to PayPal and other systems, but most forums recommend Authorize.net

I am currently learning about the basics of adding this feature to our software, but could sure use some general guidance as to how to interact with whatever product or API we will need.

Any general guidance / direction at this stage is greatly appreciated.
tia

Roy

 

[EzLogic]

I wrote a class for authorize.net

I posted it here, do a keyword search for Authorize.Net. I also posted it on Foxite.

Ez Logic
Michigan

 

[EzLogic]

Here is one i posted on FoxWeb.com

http://apps.foxweb.com/forum/MsgShow.fwx/011/004439

Ez Logic
Michigan

 

[clipper01]

Interesting timing, if you look at the recent thread on linking VB.net to FoxPro, we all agreed that wwDotNetBridge is exactly the way to add these kind of dotNet API capabilities to a VFP application. While it is true that you could integrate authorize.net with FoxPro ( see the sample codes from other responses ), but is horribly convoluted and well nigh impossible to maintain/debug. By contrast, the authorize.net site has loads of sample code for C#. Plus you get all the developer support fro working with C#, there will be absolute zilch for VFP

What wwDotNetBridge then allows is to build all the logic /processing in a C# ( or VB.net ) form and then talk back/forth to the VFP application.

 

[Mike Lewis]

Roy, I wonder if you are going aboutt this in the wrong direction. Instead of looking for a component or other software you can use, shouldn't you first decide what payment provider you are going to sign up with? You have to choose between working directly with a bank, using a third-party provider such as WorldPay, or opting for some other solution such as PayPal.

These various systems all have their pros and cons (not least of which is the cost, which could be a lot of higher than you might think). The point is that it's really a business decision, not a programming one.

Once you have decided on your provider, you can start looking at the technical aspects - not the other way round.

Just a thought.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[clipper01]

Regardless of which you choose , WorldPay , Paypal , Authorize or other, the dotNetBridge method is still an excellent way to integrate to your VFP application, presume its a Card Not Present situation. They ALL have C# interfaces and LOADS of support , ZERO of them have VFP interfaces and ZERO-ZILCH support

 

[Mike Lewis]

Clipper, I don't disagree with that. But I really think the business decision is far more important than the programming one. The choice of provider / payment method could have a big effect on your marginal costs, cash flow, customer service, and - importantly - the customer's perception of the quality of your service. You have to get that decision right first, otherwise there's a danger that you will choose a solution purely on the basis of how well it meets your technical requirements, not the other way round.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[clipper01]

True, and don't forget to include Stripe in the line-up, amazing success story of Patrick Collison, who incidentally is back in 'town' at the web summit in Dublin this week

 

[OldxBaser]

Thank you everyone for taking the time to give me feedback.
It is very much appreciated ...
I will review all your suggestions and re-think my entire approach.

Again ... thanks.
Roy O'Neil

 

[clipper01]

Also bear in mind that when you look at all of the reviews of these various systems, they generally talk of " integrating to web-sites " etc. But what makes the dotNetBridge angle really interesting from a VFP view is that the linkage is direct form-to-form , so e.g. your VFP form could pull some billing details from your app ( presume it is some of service/sales app), send the details to the payment interface via the dotNetBridge form and get back the completion codes etc to then update your VFP tables ( dotNetBridge is free, check out

http://west-wind.com/wwDotnetBridge.aspx

)