I work at a web hosting company, and am working on impelementing OpenSRS
for our site. Before this goes live, I will have to implement credit card
processing, and afterwards, we will consider whether to release our
modifications back to the community.
So far, I think I understand how the reg_system.cgi script works; I have
some ideas, and I see a few potential snags. I'd probably be adding my
code and function calls to register and do_bulk_transfer. Any help,
advice, or code would be appreciated.
The helper functions I'd want to add to implement this are as follows:
lookup_price -- look up the price for registering or transferring a
domain, probably by passing it $data{"reg_type"}, and returning the
price. How it does so isn't that important right now; we'll probably
use MySQL.
domain_charge -- charge a credit card for the number of domains processed.
This will need to know the price per domain, the number of domains
registered, the credit card / billing info, and somehow create an order id
and return a success / fail code. The price per domain and number of
domains I can pass as arguments, or simply multiply them and pass the
final price. The number of domains to register is easy to get, but there
are other snags, and also with the order_id.
domain_credit -- similar to domain_charge, or possibly just another
option to that function instead; credits a credit card for a given amount.
The problematic issues are as follows:
When a domain is registered successfully, we get billed, and are
responsible for that domain. Therefore, the client should always
get billed for this first; otherwise, we could be liable for many
"free" domain registrations.
Therefore, the client's credit card should be checked or billed first.
We're using CyberCash for this, and AFAIK, we'll have to bill them for
the amount. We also want this to be completely automated, so even if
we could use batch transactions, we wouldn't want to review them.
However, if the client gets billed for, say, five domains and two of them
fail for whatever reason, we need a way to give them that money back.
Hence, the domain_credit function: this could be implemented with the
CyberCash 'return' or 'void' function, and I'm leaning towards 'return'
here. But I don't have much experience with CyberCash yet, so we'll see.
Now CyberCash and OpenSRS both have some notion of using order ids to
track customers and customer information. I think this is a great idea,
and the right way to do this would be to use one id, and potentially store
this information in a database somewhere, as needed. However, the OpenSRS
id is created *after* the transactions take place, and the CyberCash id
would be needed beforehand, to charge the credit card.
So either there would have to be two separate ids, (you could put them
both in the database, but it would be a messy solution) or you'd have to
be able to specify or query for an id for OpenSRS, or change one in
CyberCash, or bill the client later (but be absolutely sure they have the
requisite funds). I don't know if there's a good way to do any of these
things, so we might be stuck with two order ids. Also, I don't know if
we'll be able to use mauthonly transactions; apparently this depends on
our setup with the bank, and I have a feeling we'd only be able to use
mauthcapture.
I think that's everything, but let me know if I missed something. I'm
somewhat new to CyberCash and OpenSRS.
Any questions or comments?
Anyone want to help me design or develop this?
---
Peter Baylies
American Data Technology
