wooo... another question on internet merchant accounts!

Discussion in 'OT Technology' started by crotchfruit, Nov 5, 2003.

  1. crotchfruit

    crotchfruit Guest

    ok, so i want to let people use credit cards on my website.

    i did some research, including reading these two threads:

    http://forums.offtopic.com/showthread.phpt=858422
    http://forums.offtopic.com/showthread.php?t=836759

    so this is the ideal situation as i understand it (btw, am using PHP as the main scripting language):

    - user comes to site (http)
    - user decides to buy product
    - user goes to "checkout screen" (https between my site and user from now on)
    - user enters CC info, submits
    - script does preliminary CC checks (Astro sugg. in one of his posts.)
    - script connects to gateway for CC processing via SSL connection
    - script gets return code, presents result to user
    - store only result + date + remote IP/host + last four CC numbers in DB.

    if this is correct, then the next question is.. how to i keep the user on my site?

    i've found that most merchant account dealios make the user leave your site to go to their own CC processing page. i don't want this. i want to have my site be able to contact the gateway itself so that the user stays in my domain.

    i've seen the verisign payflow pro thing, and they even have php extensions. here is the url btw: http://www.verisign.com/products/payflow/pro/index.html. this looks really nice and is, as far as i can tell, what i'm looking for, except that cost of entry is a bit steep (to me, at least.) obviously i will have to pay for this if it is the only option. does anyone have experience with this? is this payflow pro the only thing i need to pay for to get a complete, functional chain between the customer and my bank account?

    are there other products that provide all of the features as payflow pro (i.e. php extensions so i can embed functionality into my site), but that are cheaper?

    does anyone here have a merchant account, or do CC processing on their site, and have any experience with this?

    thanks for the help :)
     
  2. crotchfruit

    crotchfruit Guest

  3. Astro

    Astro Code Monkey

    Joined:
    Mar 18, 2000
    Messages:
    2,047
    Likes Received:
    0
    Location:
    Cleveland Ohio
    I haven't seen this sooner. Uber busy with 2 jobs and a math class that is trying to kick my ass! (I'm taking it again in revenge for the D I got the first time)

    This is perfect...

    What you're asking about is the payment gateway and how to interface to one. I'm not a big fan of VeriSign. Anything they have is just expensive. And are they the jackasses that are doing that sitefinder crap?

    You need a payment gateway that allows for direct interaction (aka: no hosted solutions junk) and you need a payment gateway friendly to your server and scripting language. There's a lot of payment gateways that like to use a DLL to handle server interaction and this doesn't work on a *nix solution.

    I've dealt with about a half dozen different payment gateways, like CardServices (yuck), Authorize.net (expensive the last time I checked), WorldPay (they still in business?), 5/3rd Bank (they had the technical ability of a rock), Planet Payment (I think they're still in business), and probably a few others that I've forgotten about (I know I've worked with some British bank, but I forgot the name).

    These guys are the gateway between your bank account and your customers credit card(s). Some will have about 5 different ways to setup the checkout and others may only have 1 or 2 (by default, its usually some HTML hosting solution which you don't want or the 2nd being a way to transmit the data from your server to theirs - which IS what you want). You need to get hooked up with one that can do this (maybe Verisign can and you just have to figure out which "plan" they call it).

    Ok, so you get hooked up, then what?

    You read the specs. Sometimes they have awesome documentation, sometimes you're stuck trying to figure out if they're still talking about a payment gateway (haven't had that too often). The biggest problem I found with the documentation was figuring out which payment setup you went with and which payment documentation you need to read. Its easy to get lost with a POST submit versus an encrypted GET submit. Either way, you'll figure it out. Also, each gateway will do it differently, so don't get too excited about porting your code UNLESS you're smart about it and create a class to wrap around the payment functions (we did this and it really cut down on our development time as we switched from one processor to the next). This of course is completely optional and I'd predict you're interested in just making it work.

    You'll need to look at the gateway's specs to determine how they want the data organized and sent. In the methods I've seen us use, it can range from a simple encrypted GET request submitted to their servers for processing (in which the resulting page is read in with data - usually encrypted). They may also use SOAP/XML or some specially designated socket connection (don't worry, PHP loves doing this type of stuff). Watch for their encryption method - they may provide you with their own encrypt/decrypt tool (such as a DLL or maybe a *nix executable). Some may even go another step further and provide a tool that completely handles the entire transaction and returns a result to you (wouldn't that be nice!). Either way, there usually is some more error checking you have to do to validate the transaction made it to the gateway ok and the gateway approved the transaction. This validation is really really important because if the gateway doesn't approve, but you miss it, you may be selling an item you won't be getting paid for. But this checking is usually pretty easy and can end up being as simple as an if() with a check for a code to be in a certain range or value.

    This transaction between your web server and the gateway can all take place when the user clicks the submit button to process their order. The time it takes to validate a card number is anything up to about 30 seconds, which is still acceptable. You just add some code after you validate the card number (making sure its not fake, bogus, or whatever) to handle the gateway transaction and then after the transaction, you show a receipt page with a message appropriate to how the transaction went (and also log it in your database).

    There are tricks you can do to have a user to go a completely different server and return back. We did that in house because we had a dozen servers, but only wanted to pay 1 SSL license so we kicked all the users to our dedicated secure server that had a generic (but customizable to fit the site look/feel) checkout page. This worked out well, but you really have to concentrate on security, which really doesn't require much if the web server, database, and SSL server are on the same network (in this case, the web server just needs to know what receipt page to show if the transaction was good or not).

    I've got some consulting to do this weekend, but hit me up on IM if you get stuck or have questions. Its been a year or two since I last played with CC but I shouldn't be too rusty (in fact, I've got two clients needing to have this done so I've got to get my butt in gear).
     
  4. crotchfruit

    crotchfruit Guest

    yowsa.. thanks for the response :)

    i was looking at VeriSign, and it's $250 for setup, $60 a month for 1000 transactions, and something like $800 a year for an SSL certificate :eek3:

    now that i have a list, i'll go check out some of those other gateways you've suggested. it seems the hardest part in this whole process is finding which gateways will do the direct-authorization scheme instead of the user-must-pay-on-their-site thing :/

    i haven't gotten to the actual CC implementation phase.. i was just researching to make sure it was possible once i'd finished the rest of my site. but i'm sure i'll have more questions once i'm there :yum:

    thanks for the help though :bowdown: :bowdown:
     
  5. Astro

    Astro Code Monkey

    Joined:
    Mar 18, 2000
    Messages:
    2,047
    Likes Received:
    0
    Location:
    Cleveland Ohio
    Instead of looking at gateways (like the ones I mentioned), you might want to talk to your bank (or the bank you plan on having the CC money go to). The reason being is THEY are the ones the money has to get to. They should know (unless its 5/3rd Bank and then they just don't know) which gateway they prefer (sometimes the bank may want you to use their gateway, sometimes they have 2 gateways to pick from, or they may not care). Either way, ask them for whatever paperwork you can get your hands on. They may not want to give any if you haven't signed any papers (such as signing up for a merchant account or something).

    Take a step back from Verisign and think about it.

    SSL certs are what? $400-500 for 1 year and 128bit I think? Where is Verisign going with $800!?

    Gateway transaction charges typically had been around $25 a month. Depends on how many transaction you're doing though. Don't quote me on this price. Its been a couple years.

    Depending where you go, you may feel the pinch of a setup fee and $250 is about average to being on the high side (expect maybe $150-$300 for setup). Again, just wild guessing here.

    Check out your bank. They should be able to give you the scope on whats up or they should be able to recommend some places to go to get hooked up. Essentially, there's no really good reason to go with Verisign as long as you're willing to do a little leg work...
     
  6. NolanTA

    NolanTA You talkin' to me? OT Supporter

    Joined:
    Oct 9, 2002
    Messages:
    2,397
    Likes Received:
    0
    Location:
    Dallas
    My company uses GoEmerchant for several clients, and it uses a pretty standard http form submittals (or soap) to pass CC info in, and then querystrings to pass CC verification/auth stuff back to our host site..

    Works pretty well, and I think they're only $40/month (but I'm not sure..) They have decent support from the few times I've called, their admin site works okay, and the interface has good enough docs that we've pretty much got their system down and can produce a store/cart system pretty quick.
     

Share This Page