For this example, authentication is performed using an API login ID and transaction key.
Sample Authentication Structure
The first value to specify for any transaction request is what type of transaction to process. When you use the credit card payment type, you can choose between either authorize-only (authOnlyTransaction) or authorize-and-capture (authCaptureTransaction). The default if no transaction type is specified is an authorize-and-capture transaction type, however, the recommended best practice is to always explicitly identify the transaction type.
Sample Transaction Type Declaration
The payment amount is the only paramter that is absolutely required other than the payment details. The payment amount should be specified using standard decimal notation. The currency type is not defined in this field.
Sample Amount Structure
The payment object includes the required details for the method of payment. This can be credit card details, bank account information, or tokenized payment information from a service such as Apple Pay.
A traditional credit card is, by far, the most commonly used payment type for processing a transaction. Credit cards can be used for any API call that takes the
payment type object as an input.
When charging a credit card, you will need at least the card number and expiration date. For improved security, we strongly recommended that you also collect and validate the Card Code. When testing in the sandbox environment, you can use test-card numbers. For more information about testing, see our Testing Guide.
Credit Card Form Fields
|The 13-16-digit credit card number.||16-digit, Numeric.||Yes|
|The credit card's expiration date (month and year).||MMYY||Yes|
|The 3 or 4 digit card code.||3-4 digit, numeric||No|
Credit Card Payment Structure
The order information is not required, but is stored along with the transaction at Authorize.Net. Including the order information enables you to more easily identify transactions for your account and makes the data available to other applications that integrate with the same Authorize.Net account, for example, reporting or analytics applications. In some cases, the invoice number may also be passed to the card-issuing bank during a credit card authorization.
The two basic fields for order information consist of an invoice number and an order description.
Sample Order Object
Line Item Details
For even more precision in your reporting, you can also provide a further breakdown of data into line item details, which include individual item prices, descriptions, and quantities.
Sample Line Items
The customer details include your own unique identifier for the customer along with the email address to be used for communication such as email receipts.
The billing address is strongly recommended for the purposes of address verification when processing a credit card. The address is not validated for all payment types and not every field is validated even for credit cards, but it is a best practice to capture the full address.
Sample Billing Address
The shipping address does not apply in all scenarios, but is still a common element for most payment transactions. This address is not validated against the payment method, but it can be validated as a real, shippable address by using the Advanced Fraud Detection Suite.
Sample Shipping Address