+Customer's social security number.
+
+=item license_num
+
+Customer's driver's license number.
+
+=item license_dob
+
+Customer's date of birth.
+
+=back
+
+=head3 RECURRING BILLING FIELDS
+
+=over 4
+
+=item interval
+
+Interval expresses the amount of time between billings: digits, whitespace
+and units (currently "days" or "months" in either singular or plural form).
+
+=item start
+
+The date of the first transaction (used for processors which allow delayed
+start) expressed as YYYY-MM-DD.
+
+=item periods
+
+The number of cycles of interval length for which billing should occur
+(inclusive of 'trial periods' if the processor supports recurring billing
+at more than one rate)
+
+=back
+
+=head2 test_transaction()
+
+Most processors provide a test mode, where submitted transactions will
+not actually be charged or added to your batch, calling this function
+with a true argument will turn that mode on if the processor supports
+it, or generate a fatal error if the processor does not support a test
+mode (which is probably better than accidentally making real charges).
+
+=head2 require_avs()
+
+Providing a true argument to this module will turn on address
+verification (if the processor supports it).
+
+=head1 TRANSACTION SUBMISSION METHOD
+
+=head2 submit()
+
+Submit the transaction to the processor for completion.
+
+If there is a gateway communication error or other "meta" , the submit method
+will throw a fatal exception. You can catch this with eval {} if you would
+like to treat gateway co
+
+=head1 TRANSACTION RESULT METHODS
+
+=head2 is_success()
+
+Returns true if the transaction was approved by the gateway, false if
+it was submitted but not approved, or undef if it has not been
+submitted yet.
+
+=head2 partial_auth_amount()
+
+If this transaction was a partial authorization (i.e. successful, but less than
+the requested amount was processed), then the amount processed is returned in
+this field.
+
+(When is_success is true but this field is empty or 0, that indicates a normal
+full authorization for the entire requested amount.)
+
+=head2 error_message()
+
+If the transaction has been submitted but was not accepted, this
+function will return the provided error message (if any) that the
+processor returned.
+
+=head2 failure_status()
+
+If the transaction failed, it can optionally return a specific failure
+status (normalized, not gateway-specific). Currently defined statuses
+are: "expired", "nsf" (non-sufficient funds), "stolen", "pickup",
+"blacklisted" and "declined" (card/transaction declines only, not
+other errors).
+
+Note that not all processor modules support this, and that if supported,
+it may not be set for all declines.
+
+=head2 authorization()
+
+If the transaction has been submitted and accepted, this function will
+provide you with the authorization code that the processor returned.
+Store this if you would like to run inquiries or refunds on the transaction
+later.
+
+=head2 order_number()
+
+The unique order number for the transaction generated by the gateway. Store
+this if you would like to run inquiries or refunds on the transaction later.
+
+=head2 card_token()
+
+If supported by your gateway, a card_token can be used in a subsequent
+transaction to refer to a card number.
+
+=head2 txn_date()
+
+Transaction date, as returned by the gateway. Required by some gateways
+for follow-up transactions.
+
+=head2 fraud_score()
+
+Retrieve or change the fraud score from any Business::FraudDetect plugin
+
+=head2 fraud_transaction_id()
+
+Retrieve or change the transaction id from any Business::FraudDetect plugin
+
+=head2 response_code()
+
+=head2 response_headers()
+
+=head2 response_page()
+
+These three fields are set by some processors (especially those which use
+HTTPS) when the transaction fails at the communication level rather than
+as a transaction.
+
+response_code is the HTTP response code and message, i.e.
+'500 Internal Server Error'.
+
+response_headers is a hash reference of the response headers
+
+response_page is the raw content.
+
+=head2 result_code()
+
+Returns the precise result code that the processor returned, these are
+normally one letter codes that don't mean much unless you understand
+the protocol they speak, you probably don't need this, but it's there
+just in case.
+
+=head2 avs_code()
+
+=head2 cvv2_response()
+
+=head1 MISCELLANEOUS INTERNAL METHODS
+
+=head2 transaction_type()
+
+Retrieve the transaction type (the 'type' argument to contents()).
+Generally only used internally, but provided in case it is useful.
+
+=head2 server()
+
+Retrieve or change the processor submission server address (CHANGE AT
+YOUR OWN RISK).
+
+=head2 port()
+
+Retrieve or change the processor submission port (CHANGE AT YOUR OWN
+RISK).
+
+=head2 path()
+
+Retrieve or change the processor submission path (CHANGE AT YOUR OWN
+RISK).
+
+=head1 HELPER METHODS FOR GATEWAY MODULE AUTHORS
+
+=head2 build_subs( @sub_names )
+
+Build setter/getter subroutines for new return values.
+
+=head2 get_fields( @fields )
+
+Get the named fields if they are defined.
+
+=head2 remap_fields( %map )
+
+Remap field content (and stuff it back into content).
+
+=head2 required_fields( @fields )
+
+Croaks if any of the required fields are not present.
+
+=head2 dump_contents
+
+=head2 silly_bool( $value )
+
+Returns 1 if the value starts with y, Y, t or T.
+Returns 0 if the value starts with n, N, f or F.
+Otherwise returns the value itself.
+
+Use this for handling boolean content like tax_exempt.