notes_for_module_writers

   1 These are the old v2 notes.  Business::OnlinePayment::OpenECHO is the first
   2 "v3-ish" module, if you're writing an HTTPS-interface module, try starting
   3 from there until there's better v3 module writer's docs.
   4
   5 $Id: notes_for_module_writers,v 1.2 2004-09-03 23:20:25 ivan Exp $
   6
   7 Information on creating a new processor backend to go with
   8 Business::OnlinePayment.
   9
  10 create a subclass of Business::OnlinePayment called
  11 Business::OnlinePayment::(processor name).  You should override at least
  12 the following functions (look at Business::OnlinePayment::AuthorizeNet as
  13 an example).
  14
  15 set_defaults: set default information for server/port/path (if your processor
  16               is not web based you probably dont need to override these).
  17
  18 submit: This is the only function you _MUST_ override, the superclass function
  19         merely dies(), so if you dont override this, your module doesnt do
  20         anything.  Some of the things that submit should do:
  21
  22             * Turn the data into a format usable by the online processor,
  23               some convenience functions (remap_fields and get_fields), are
  24               provided by the superclass to make this a little easier.
  25
  26             * Check and make sure that all the required fields have been
  27               filled in (the superclass provides the function required_fields()
  28               which can do this for you).
  29
  30             * IMPORTANT: If the superclass function test_transaction() returns
  31               true, the transaction must be submitted to the processor in test
  32               mode.  If your processor is unable to easily provide a test mode,
  33               your module should die() if test_transaction() returns true,
  34               this prevents accidental charges for people who thought they were
  35               submitting test transactions.
  36
  37             * If your processor provides an option of whether or not you want
  38               address verification, your module should check to see if the
  39               require_avs() function returns true, and turn on AVS checking if
  40               it does.
  41
  42             * Submit the transaction to the processor and collect a response.
  43
  44             * Do the following with the response:
  45               * call server_response() with a copy of the entire unprocessed
  46                 response, to be stored in case the user needs it in the future.
  47               * call is_success() with either a true or false value, indicating
  48                 if the transaction was successful or not.
  49               * call result_code() with the servers result code (this is
  50                 generally one field from the response indicating that it was
  51                 successful or a failure, most processors provide many possible
  52                 result codes to differentiate different types of success and
  53                 failure).
  54               * If the transaction was successful, call authorization() with
  55                 the authorization code the processor provided.
  56               * If the transaction was not successful, call error_message()
  57                 with either the processor provided error message, or some
  58                 error message to indicate why it failed.