Making Money with osDate

Return to the Index

Ready to start printing your own money? Well, not literally of course. But with online dating systems it's nearly that easy. There is essentially no startup capital - just a website (about $10 / month) and osDate ($0), and you're ready to start accepting money from millions of singles world-wide.

To get started, you should set up some type of membership structure with your osDate installation. For example, you might offer to give higher-payment customers a greater level of access to your system. Depending on the version of osDate that you are using, your interface may look different from those shown below.

SSL or non-SSL?

Whether you have SSL (https://) available on your server, and a signed certificate correctly installed, will determine the payment method to use. If you do NOT have an https server available, then you should the non-integrated methods described below. This means that your customers will input their payment information (credit card number, credit card expiration date, etc.) on a remote server, for example the PayPal server. If you DO have an https server available, you may have your customers input their credit card information on your server. This can make your system look more streamlined and professional, since users will never visibly leave your domain.

It's strongly recommended that new users choose the non-integrated payment methods. Thus, to pay for your dating service, your users will temporarily leave your domain to input their payment data, then they will return to your domain after successful payment.

Payment Interfaces

osDate's payment gateway API is nearly identical to osCommerce's payment gateway API. This is because the osCommerce classes were used as a starting point for the osDate API. You can read more about osCommerce at http://www.oscommerce.org. It is an open-source e-commerce system.

The idea of an "interface" is that it provides a common set of functions across all possible payment gateways. This interface provides the following functions:

pre_confirmation_check()
confirmation()
process_button()
... and many others ...

Some classes, like authorizenet.php, contain auxilliary functions such as "hmac ( $key, $data )" that only exist within those files. For this reason, these files aren't really true interfaces in the object-oriented sense, but they are "interface-like" to some extent.

The idea is that to add new payment gateways to osDate, you simply have to create - or otherwise aquire (hint: there are several on osCommerce's website) - the interface, then add it to the /modules/payment/ folder, then add the module data to the osdate_payment_modules database table, and finally add any module-specific constants to the osdate_configuration table.

A more in-depth tutorial on adding new payment interfaces will be available in mid-2006, as the payment API is further developed.