[ic] Payment Gateways

[Daniel Davenport]

>>> daniel_castro at hotmail.com 02/18/05 10:01PM >>> 
> Hi List, 
> Can some one explain me how the payment gateway system works. 
> 
> I need to send some info via a post to a bank server, the server will
reply 
> with another post, and then I should complete the order process and
print 
> the receipt. 
> 
> Any help will be apreciated. 
> Daniel Castro 

The current system was designed more to work with gateways that return
a reply in the same post as yours. That is, you post the info, and the
server responds to the post by returning a page that says "success" or
"failure" or a status code or a query string containing reply variables,
depending on the gateway. If that's how your gateway works (and fwiw
it's how most of them work), then you can either take an existing module
and change the post variables' names, or perhaps find a module already
made to talk to your bank. 

If your gateway does indeed reply in a separate post, then things get a
tiny bit more complicated. Real-time confirmation (as in returning a
page to the customer that says "your order was placed successfully")
gets a little more fragile. If you can do without it, just record the
important info--order number, amount, etc) in a table, post the info,
and have a page that accepts the gateway's reply and updates the order's
status in your table.

Note that your module should record the info in its own table (which
probably shouldn't be "transactions"), and the accept-reply page should
work with that table, unless you can guarantee that the charge won't
happen before the info gets inserted.  Otherwise, you might just get a
confirmation for an order that doesn't exist yet.  :)  transactions is
outside of the IC core, as i've recently found out, so the location of
the [charge] tag (or &charge= profile thingie) is pretty important.

If you want to be a bit more tolerant, you can have a confirmations
table, which might contain nothing more than order_number,
reference_number, and status.  A "confirmed" order would then be an
order that has a matching line in that table, which the accept-reply
page would insert confirmation info into. That way, it wouldn't matter
whether the confirmation arrived before or after the logging in
transactions.  However, if you don't set some kind of access check on
that page, some kiddie could fill up your server with "confirmations",
or 

If you want real-time confirmation, a la the receipt page, then the
"receipt" page could bounce to "order status" (with the order number, of
course), and order_status would do one of two things...if the
confirmation has been received then it shows a receipt, else it shows a
"processing order..." page and refreshes itself every 5 seconds or so
til the confirmation is received.

/