1 These are the module writer's notes for v3. See the regular
2 "notes_for_module_writers" file first.
5 - If your gateway is HTTPS-based, use (or convert to)
6 Business::OnlinePayment::HTTPS !!
11 - If your processor module encounters a setup problem, communication
12 error or other problem that's prevents the card from even being
13 run, you should die (or croak) with a useful error message. Setting
14 is_success to 0 and returning normally should only be done when the
15 transaction *processing* was sucessful (or at least elicited some sort
16 of result from the gateway), but the transaction itself returned a
17 "normal" decline status of some sort.
19 - (NEW IN 3.00_04) You should set "failure_status" depending on the
20 specific failure result, if (and only if) the failure results from one
21 of the defined statuses:
24 - "nsf" (non-sufficient funds / credit limit)
28 - "inactive" (inactive card or not authorized for card-not-present) (?)
29 - "decline" (other card/transaction declines only, not other errors)
31 You should use code like this so your module can work with B:OP versions
34 $self->build_subs('failure_status') unless $self->can('failure_status');
36 (or add "failure_status" to your build_subs call if you have one during
40 - (NEW IN 3.01) Introspection:
42 - Add an _info subroutine to your module that returns a hashref of
47 'info_compat' => '0.01', # always 0.01 for now,
48 # 0.02 will have requirements
49 'gateway_name' => 'Example Gateway',
50 'gateway_url' => 'http://www.example.com/',
51 'module_version' => $VERSION,
52 'supported_types' => [ qw( CC ECHECK ) ],
53 'token_support' => 0, #card storage/tokenization support
54 'test_transaction' => 0, #set true if ->test_transaction(1) works
55 'supported_actions' => [
56 'Normal Authorization',
65 # or a more complicated case:
69 'info_compat' => '0.01', # always 0.01 for now,
70 # 0.02 will have requirements
71 'gateway_name' => 'Example Gateway',
72 'gateway_url' => 'http://www.example.com/',
73 'module_version' => $VERSION,
74 'module_notes' => 'usage notes',
75 'supported_types' => [ qw( CC ECHECK ) ],
77 'test_transaction' => 1,
78 'supported_actions' => { 'CC' => [
79 'Normal Authorization',
84 'Recurring Authorization',
85 'Modify Recurring Authorization',
86 'Cancel Recurring Authorization',
89 'Normal Authorization',
94 'CC_void_requires_card' => 1,
95 'ECHECK_void_requires_account' => 1, #routing_code, account_number, name
100 - authorization and order_number (NEWLY DOCUMENTED IN 3.01):
102 Gateways will return one or two values from Authorization Only and
103 Normal Authorization transactions that must be submitted back with a
104 Post Authorization, Void, or Credit transaction.
106 If the gateway returns one value, return this as "authorization"
108 If the gateway returns two values, return one as "authorization" and the
109 other as "order_number". Typically "authorization" is the more low-level
110 value returned from the underlying processing network while "order_number"
111 is a unique tranaction id generated by the gateway.