Forum Moderators: buckworks

Message Too Old, No Replies

Accepting payments without leaving the domain?

What is the standard terminology that I should look for?

         

JAB Creations

8:20 pm on May 28, 2010 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



I need to setup a site to accept payments however I don't want to have paying clients leave our domain name (e.g. example.com --> example-payment.com --> example.com) so what is the terminology I should look for when browsing merchants? Also I'm not really sure where to look...is there a standard term for companies that provide this service as in example a company that has a computer that a site is hosted on is called a "web host" in example of where my line of thought is on the topic.

- John

lorax

8:32 pm on May 28, 2010 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



You're in need of a payment gateway.

Options include:
  • Authorize.net
  • PayPay
  • 2CheckOut
  • Google Checkout
  • Amazon Payments
  • WorldPay
  • SagePay
  • LinkPoint

    and many more... [google.com]
  • ergophobe

    4:43 am on Jun 18, 2010 (gmt 0)

    WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



    PayPay


    Paypal perchance?

    lorax

    10:08 am on Jun 18, 2010 (gmt 0)

    WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



    LOL - yes

    rocknbil

    4:19 pm on Jun 18, 2010 (gmt 0)

    WebmasterWorld Senior Member 10+ Year Member



    I don't want to have paying clients leave our domain name . . . so what is the terminology I should look for when browsing merchants?


    There may be other names for it, but the most common one is silent post. Most robust processors support it.

    Generally (of course) it requires posting to the gateway only from a valid SSL connection. The trick is to curl (or PHP's implementation) as a part of the auth/charge process.

    You're sitting on the checkout page with the CC info fields, etc., post to checkout.php/cgi/asp etc.

    -- Do what you do with input

    -- curl using the post method to the processor. Generally this takes the form of a query string or an XML string. The general process is

    $result = `curl -d [query string] [post url]`;
    (PHP method is similar)

    The response in $result is generally also a query/XML string, but what you're looking for is the approved/declined(etc.) code value. Based on the response,

    - if error, return to checkout form with error displayed. For security considerations, most API integration guides recommend it's "good practice" not to display the specific error (invalid card, declined, etc.) But it's **always** a good idea to log API responses.

    - if approved, update your database, send the emails, return a response to the browser.

    Customer never leaves your site.

    incrediBILL

    4:33 pm on Jun 18, 2010 (gmt 0)

    WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



    The downside with silent post is that when a transaction goes south your customer doesn't have as much control over recovering from the problem than they would if you just transitioned to PayPal for instance.

    Mostly it's because cart designers are lazy and don't give the customer enough information on what really happened over than "YOUR CARD WAS DECLINED" instead of specifics.

    Then when they give specifics it's something stupid like "DECLINED DUE TO AVS ERROR" like your customer knows what AVS, CCV or any of that lingo which sites like Paypal will hold their hand through.

    I use silent post myself, standard CC processor (not PayPal) but if it fails I also slap a big fat "CHECK OUT WITH PAYPAL" button on the fail page to attempt to capture the customer no matter what.

    Also, most of the payment processors will direct the customer back to your website at the end as long as you supply the return URL page.

    Last but not least, you will always lose customers that don't want to give you all their personal information, don't trust your site with their CC details, that feel more comfortable using PayPal or Google Checkout, so making those options available will result in more sales.

    At the end of the day it's all about capturing the sale, not staying on your domain name.

    wyweb

    4:44 pm on Jun 18, 2010 (gmt 0)



    most of the payment processors will direct the customer back to your website at the end as long as you supply the return URL page.

    Yes, they will. Many of them will allow you to specify different pages for different actions as well. Payment confirmed can direct to one page for example. Payment pending to another. This is especially useful when a purchase gets held up for further fraud verification. It's nice to be able to put your customer on a page that will explain to them exactly why their purchase is being delayed, how long it might be delayed for and contact information in case they insist on talking to somebody about it.

    As Bill said, it's all about capturing the sale. I try to keep them calm too.