-Note that (as of Aug 2006) this is only supported by some of the
-newest processor modules, and that, even if supported, a failure
-status is an entirely optional field that is only set for specific
-kinds of failures.
+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. Store this if you would like to run inquiries or
+refunds on the transaction later.
+
+=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.