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