• Protip: Profile posts are public! Use Conversations to message other members privately. Everyone can see the content of a profile post.

payment processing gateway

robr

robr

Legendary Member
Joined
31 July 2001
Messages
5,193
Location
Boston, MA
I know a couple of you here have companies that do this. Please PM me, I'm looking for a competitive solution to integrate with our software product. Also let me know why I should choose you over one of the 800lb gorillas.

Note I would like to avoid as much of PCI DSS as possible, so I don't want to maintain any CC info locally, I just want to pass it on (preference will be given to companies that have a web service based interface) and get back a status and transaction number, etc.
 
Thanks, interesting stuff about Digital River. However it looks like these kind of services aren't what I'm looking for. They seem more geared toward online stores, shopping carts, etc and take pretty large %ages of the payments, so let me clarify.

What I need is just to process payments from within our custom J2EE application. We write B2B collections software, if a collections agent is on the phone with one of their customers and their customer wants to make a payment, I want that CSR to be able to key in the CC info to our software, send the info via our software to a CC processor (preferably via web service), and have the CC processor validate it all and forward the payment to our customer's merchant account, while just handing back a status/transaction # to our software so we can tell the CSR the payment has been declined/made, etc and write the transaction number as a note to the customer file.
 
I use paypal.....

DO you really want the cc info local??? I dont....Let that be paypal problem if something goes wrong...I am in the IT feild and rather have their 24/7 staff maintain that....No GAteway fee
 
prestonmay said:
I use paypal.....

DO you really want the cc info local??? I dont....Let that be paypal problem if something goes wrong...I am in the IT feild and rather have their 24/7 staff maintain that....No GAteway fee
Click to expand...

Like I said, no, I don't want the cc info locally other than to take it and pass it on. Something like Paypal is NOT an option in a B2B world. Our customers already have merchant accounts and need to be able to accept credit cards from within our application and have those funds deposited to their merchant account. It's very simple and it's done every day to the tune of billions of dollars in the B2B world. There are a couple of guys here that do this for a living that have contacted me previously about this via PM but I had to keep purging my PM boxes to keep under the limit and no longer have their info. I got their attention by posting in off topic previously, so figured I'd a) try it again and b) see what others are using.

I too am in IT and don't need a 24/7 staff to do what I describe. It's just a simple gateway. I pass (via an encrypted service) the CC info, I do not save it in any way locally, the payment processor handles the transaction and just passes me back a success or fail (with reason code) and a transaction number. The only thing I save is the transaction number or failure reason. Doing it this way should allow me to bypass most of the PCI DSS requirements one is supposed to comply with (as set forth by the credit companies) when allowing CC transactions.
 
I use Authorize.net. They have a nice interface for both back end and front end. Nice verification and fraud suites also.
 
I've also used Authorize.Net. You send a plain old HTTP POST to their AIM server and it returns a response which includes status and confirmation number. It's pretty trivial to write your own wrapper to handle the interaction (basically building the request and parsing the response) or you can download a library to do it for you.

I've used a couple free libraries, but they were ASP.Net and ColdFusion. I'm guessing you could probably find a Java variant, though.

Here's some sample code. It's C#, but it should be pretty easy to convert to Java.

Authorize.Net's developer site has some sample code, too.
 
I am the founder of EmerchantsGroup.com. Excuse the self-promotion, but we offer a merchant processing program (thru First Data/11 billion dollar company) which might work for you. The merchant processing program is compatable with Authorizenet which is the most popular gateway provider. Your software provider can tell whether they are or are not compatable with Authorizenet.

I launched this program in 2002 and to date over 700 merchants are using it.

Here is a link and I hope this helps:

http://www.emerchantsgroup.com/crcase.html
 
I am the software provider. Can you explain to me why I need a merchant provider?

I've never done this before but my understanding of the logistics are

my software which we license to customer ABC (which needs to include code to interface with the payment processor) ----> payment processor (like authorize.net) ----> Customer ABC's merchant account

A user of my software enters in CC info which is then sent to the payment processor. Payment processor processes payment and sends my software a status and transaction number. In addition payment processor deposits the payment into ABC's merchant account via routing and account number (and generally takes a percentage or flat fee).

Where does EmerchantsGroup fit into this? Or did I miss a piece of the puzzle?
 
here is the flow, Back to front.

1. Processor (company that lends money to your bank until they get money from Visa, MC etc) Only 3-4 in the US

2. Merchant Provider (company that re-sells processors service) in some cases you deal direct with the processor.

3. Gateway (used for web or client side) companies like Authorize.net that secure information and send data through merchant provider to processor.

4. User interface (what the customer sees) generally a web ap' that links up with gateway for session of transaction

Hope that helps
 
VRoooM said:
here is the flow, Back to front.

1. Processor (company that lends money to your bank until they get money from Visa, MC etc) Only 3-4 in the US

2. Merchant Provider (company that re-sells processors service) in some cases you deal direct with the processor.

3. Gateway (used for web or client side) companies like Authorize.net that secure information and send data through merchant provider to processor.

4. User interface (what the customer sees) generally a web ap' that links up with gateway for session of transaction

Hope that helps
Click to expand...

Sounds like I need to care about #3 and #4 and the customer using my software that wants to accept credit cards worries about #1 and #2? That was my understanding and your explanation doesn't really change my understanding of that, though it's sort of interesting to learn about the existence of the #1 to #2 relationship.
 
Problem!!!!!

If you read the merchant agreements thoroughly - and sadly, years ago I become an expert - the CC companies, associated Banks, Processors, etc. will not accept CC charges to pay off existing consumer debt.

If you call someone who owes money - what a collection agency does - and get that person to pay on a credit card - you have violated the Merchant Agreement and are in for trouble!
 
Red said:
Problem!!!!!

If you read the merchant agreements thoroughly - and sadly, years ago I become an expert - the CC companies, associated Banks, Processors, etc. will not accept CC charges to pay off existing consumer debt.

If you call someone who owes money - what a collection agency does - and get that person to pay on a credit card - you have violated the Merchant Agreement and are in for trouble!
Click to expand...

Not a problem for me, this isn't consumer debt. As I said, this is B2B for payment of invoices that have gone beyond agreed upon payment terms (usually net 30).
 
Our ERP system integrates with Versign Payflo Pro (which is now Paypal I believe). It would be the perverbial 800 lb gorilla you speak of. It works through both web and CSR applications and doesn't retain credit card info. I know the application was written in C# (web) and VB6 (the original ERP platform) by a single developer fairly quickly, so an SDK must be available.
 
nsx2tall said:
Our ERP system integrates with Versign Payflo Pro (which is now Paypal I believe). It would be the perverbial 800 lb gorilla you speak of. It works through both web and CSR applications and doesn't retain credit card info. I know the application was written in C# (web) and VB6 (the original ERP platform) by a single developer fairly quickly, so an SDK must be available.
Click to expand...

Payflow Pro is what I initially looked at 2 years ago when it was Verisign. I had heard Paypal bought them, but had also heard that as a product it was going to be discontinued. I will revisit that option as well. Thanks for letting me know it's still around.
 
crap. payflow pro was basically shot down because of the 2.9% they take. The customers we're dealing with are used to 1% because of their volume. Of course they won't have near that volume through our application. I need to figure out how to adjust expectations as well as try to find a cheaper solution.
 
robr said:
I need to figure out how to adjust expectations as well as try to find a cheaper solution.
Click to expand...

earlier you said:
"this is B2B for payment of invoices that have gone beyond agreed upon payment terms (usually net 30)"

1) they can either pay according to term
2) they can pay outside of terms and pay the additional fee as a penalty
3) if 2, you and they can agree to split the fee and provide to them as a form of rebate / credit to bring their penalty w/in terms they can live with. (say, applied to future purchases w/terms established limiting your exposure to their continued abuse: 6 months, $ maximum applied to purchases of a specific type)
4) you can pay the "overage" and move on

hard to find a perfect solution for everyone, good luck with this.
hal
 
yeah, the problem is we're just the middle man, this isn't money owed to us. we just write B2B collections software.

the situation is a customer, let's make up a pretend company and call them FredEx.

FredEx has many customers who don't like to pay their bills after they've used FredEx' services.

FredEx has a room filled with people on phones using our software calling customers going PAY YOUR BILL OR DIE!!! BWAHAWHAHAHAHA!!!!!!!!!!!!!!

The customer says OK, OK!!! Here's my CC info!

The CC info is entered into our software, we process through some TBD 3rd party and then (hopefully) mark the invoice(s) as paid.

The only part we play in this is I have to build the UI and interface to the credit card processing company. Whatever I choose, all our customers will have to live with. I'm told that FredEx, being used to 1% would have a problem with 2.9%, so I'm doing my best to find an alternative before telling them they need to live with it and develop a business process to account for it.
 
robr said:
Like I said, no, I don't want the cc info locally other than to take it and pass it on. Something like Paypal is NOT an option in a B2B world. Our customers already have merchant accounts and need to be able to accept credit cards from within our application and have those funds deposited to their merchant account. It's very simple and it's done every day to the tune of billions of dollars in the B2B world. There are a couple of guys here that do this for a living that have contacted me previously about this via PM but I had to keep purging my PM boxes to keep under the limit and no longer have their info. I got their attention by posting in off topic previously, so figured I'd a) try it again and b) see what others are using.

I too am in IT and don't need a 24/7 staff to do what I describe. It's just a simple gateway. I pass (via an encrypted service) the CC info, I do not save it in any way locally, the payment processor handles the transaction and just passes me back a success or fail (with reason code) and a transaction number. The only thing I save is the transaction number or failure reason. Doing it this way should allow me to bypass most of the PCI DSS requirements one is supposed to comply with (as set forth by the credit companies) when allowing CC transactions.
Click to expand...

I use to maintain it in house and missed out on some sales when i was away for 3 days when a service went down....Thats the 24/7 NOC, Support, etc...I was refering too.... But I am small time... www.zygogen.com Billions of dollars is not in my realm yet, but a dream. Good Luck---But Most of assoc i know use charge.com ... I over looked the LOCAL PART..Sorry
 
I just read your site and one of us doesn't get it. All our customers already have merchant accounts. I need a payment processor, it appears what you offer is merchant accounts. I can't go tell FredEx they need another merchant account, I need to process payments and deposit them into their preexisting merchant account. I need a credit card processor that offers a Java API that will then communicate with our application.

I'm talking with Sage now, though they're being wishy-washy with their numbers.
 
Send me a PM with your contact number.
 
Rob,

I am intimately familiar with PCI compliancy and electronic payments. Check your PM – give me a call on Monday and we can chat about implementing a cutting-edge solution / methodology to give you the flexibility of a web-services based real-time API for processing electronic payments while still allowing your application to be outside the scope of PCI.
 

Similar threads

SoloNSX
'95 Autox build
2
Replies
36
Views
12K
docjohn
docjohn
Operator
Max effiency turbo build
2 3
Replies
58
Views
16K
sca037
sca037
NSX2398
NSX OEM Stereo System - 101
2
Replies
28
Views
10K
jsullyboy
J
nsxotic911
Pro bono publico IT/IS/Software Application professional consultation to 501c3
Replies
2
Views
846
nsxotic911
nsxotic911
queenlives
15 free security programs that work
Replies
1
Views
575
topman2005
topman2005
Back
Top