On This Page

Payments Developer Guide

This section describes how to use this guide and where to find further information.
Audience and Purpose
This guide is written for application developers who want to use the
REST API
 to integrate payment card processing into an order management system.
Implementing the
Cybersource
 payment services requires software development skills. You must write code that uses the API request and response fields to integrate the payment card services into your existing order management system.
Conventions
These statements appear in this document:
IMPORTANT
An
Important
 statement contains information essential to successfully completing a task or learning a concept.
WARNING
A
Warning
 contains information or instructions, which, if not heeded, can result in a security risk, irreversible loss of data, or significant cost in time or revenue or both.
Related Documentation
Visit the
Cybersource
 documentation hub to find additional processor-specific versions of this guide and additional technical documentation.
Customer Support
For support information about any service, visit the Support Center:

Recent Revisions to This Document

26.02.01

Test Cards
Added UATP test card numbers. See Test Card Numbers.

26.01.02

This revision contains only editorial changes and no technical updates.

26.01.01

This revision contains only editorial changes and no technical updates.

25.09.02

This revision contains only editorial changes and no technical updates.

25.09.01

This revision contains only editorial changes and no technical updates.

25.08.01

This revision contains only editorial changes and no technical updates.

25.07.01

This revision contains only editorial changes and no technical updates.

25.05.01

International Transaction Compliance
Added a section about international transaction compliance. See Compliance.

25.04.01

This revision contains only editorial changes and no technical updates.

25.03

This revision contains only editorial changes and no technical updates.

Introduction to Payments

This introduction provides the basic information that you need to successfully process payment transactions. It also provides an overview of the payments industry and provides workflows for each process.
With
Cybersource
 payment services, you can process payment cards (tokenized or non-tokenized), digital payments such as Apple Pay and Google Pay, and customer ID transactions. You can process payments across the globe and across multiple channels with scalability and security.
Cybersource
 supports a large number of payment cards and offers a wide choice of gateways and financial institutions, all through one connection.
Visit the
Cybersource
 documentation hub to find additional processor-specific versions of this guide and additional technical documentation.

Financial Institutions and Payment Networks

Financial institutions and payment networks enable payment services to function. These entities work together to complete the full payment cycle.

Merchant Financial Institutions (Acquirers)

A merchant financial institution, also known as an
acquirer
, offers accounts to businesses that accept payments. Before you can accept payments, you must have a merchant account from an acquirer. Your merchant account must be configured to process card-not-present or mail-order/telephone-order (MOTO) transactions.
Each acquirer has connections to a limited number of payment processors. You must choose a payment processor that your acquirer supports.
You can expect to pay these fees:
  • Discount rates: your acquirer charges a fee and collects a percentage of every transaction. The combination of the fee and the percentage is called the
    discount rate
    . These charges can be
    bundled
     (combined into a single charge) or
    unbundled
     (charged separately).
  • Interchange fees: payment networks, such as Visa or Mastercard, each have a base fee, called the
    interchange fee
    , for each type of transaction. Your acquirer and processor can show you ways to reduce this fee.
  • Chargebacks: when cardholders dispute charges, you can incur
    chargebacks
    . A chargeback occurs when a charge on a customer’s account is reversed. Your acquirer removes the money from your account and could charge you a fee for processing the chargeback.
Take these precautions to prevent chargebacks:
  • Use accurate merchant descriptors so that customers can recognize the transactions on their statements.
  • Provide good customer support.
  • Ensure rapid problem resolution.
  • Maintain a high level of customer satisfaction.
  • Minimize fraudulent transactions.
If excessive chargebacks or fraudulent changes occur, these actions might be taken:
  • You might be required to change your business processes to reduce the number chargebacks, fraud, or both.
  • Your acquiring institution might increase your discount rate.
  • Your acquiring institution might revoke your merchant account.
Contact your sales representative for information about products that can help prevent fraud.

Customer Financial Institutions (Issuers)

A customer financial institution, also known as an
issuer
, provides payment cards to and underwrites lines of credit for their customers. The issuer provides monthly statements and collects payments. The issuer must follow the rules of the payment card companies to which they belong.

Payment Networks

Payment networks manage communications between acquirers and issuing banks. They also develop industry standards, support their brands, and establish fees for acquiring institutions.
Some payment networks, such as Visa and Mastercard, are trade associations that do not issue cards. Issuers are members of these associations, and they issue cards under license from the association.
Other networks, such as Discover
and American Express
, issue their own cards. Before you process cards from these companies, you must sign agreements with them.

Payment Processors

Payment processors connect with acquirers. Before you can accept payments, you must register with
a payment processor
.
An acquirer might require you to use a payment processor with an existing relationship with the acquirer.
Your payment processor
 assigns one or more merchant IDs (MIDs) to your business. These unique codes identify your business during payment transactions.
This table lists the processors and corresponding card types that are supported for payment services.
IMPORTANT
Only the card types explicitly listed here are supported.
Payment Processor and Supported Card Types
Payment Processor
Supported Card Types
Notes
UATP
UATP

Card Types

You can process payments with these kinds of cards:
  • Credit cards
  • Debit cards
For a list of supported card types, see Payment Processors.

Credit Cards

Cardholders use credit cards to borrow money from issuing banks to pay for goods and services offered by merchants that accept credit cards.

Debit Cards

A debit card is linked to a cardholder's bank account. The funds are taken out of the customer's bank account, and the transaction is included on the customer's bank account statement. The customer does not receive a credit card bill as with a regular credit card.

Transaction Types

This topic provides information about transaction types that are supported by your processor.

Card-Not-Present Transactions

Authorizations with Card Verification Numbers

Card verification numbers (CVNs) are a required feature for the authorization service.
The CVN is printed on a payment card, and only the cardholder can access it. The CVN is used in card-not-present transactions as a verification feature. Using the CVN helps reduce the risk of fraud.
CVNs are not included in payment card track data and cannot be obtained from a card swipe, tap, or dip.
CVNs must not be stored after authorization.
IMPORTANT
In Europe, Visa mandates that you not include a CVN for mail-order transactions and not record a CVN on any physical format such as a mail-order form.

CVN Locations and Terminology

For most cards, the CVN is a three-digit number printed on the back of the card, to the right of the signature field.
For American Express, the CVN is a four-digit number printed on the front of the card above the card number.

Figure:

CVN Locations
Image depicting the location of the CVN on the back of most cards and the front of an American Express card.
Each payment card company has its own name for the CVN value:
  • American Express and Discover call it the
    Card Identification Number
     (CID).
  • JCB calls it the
    Card Authentication Value
     (CAV2).
  • Mastercard calls it the
    Card Validation Code
     (CVC2).
  • Visa calls it the
    Card Verification Value
     (CVV2).

International Transactions

Consider compliance and merchant remittance funding when processing international transactions.

Compliance

Accepting payments from a country other than your own requires that you observe the processing rules and practices of the payment systems in that country. This list describes areas of compliance that are especially important:
  • Merchant descriptor requirements—A merchant descriptor communicates merchant information to customers to remind them of the circumstances that triggered a payment. Merchant descriptors reduce the possibility of a chargeback. Accordingly, the merchant descriptor displayed on a customer’s statement should be a close match to the name on your website. It is not good practice to consolidate multiple websites into a single merchant account and use a generic descriptor that more-or-less covers all offerings.
  • Excessive chargebacks—To prevent an excessive number of chargebacks, you must maintain good customer support, rapid problem resolution, a high level of customer satisfaction, and transaction management processes that minimize fraudulent transactions. When payment card chargebacks become excessive, you must change business processes to reduce chargebacks. If chargebacks are not reduced to a satisfactory level, your account can be terminated.

Merchant Remittance Funding

You can request that the transaction proceeds be converted to another currency. Currency conversion uses a foreign exchange rate to calculate the conversion to the requested currency. The foreign exchange rate might be explicitly stated as a rate or implicitly stated as a transaction amount. The funded amount and can vary from day to day. The foreign exchange rate might also include an increase for the foreign exchange risk, sales commissions, and handling costs.

Payment Services

Various services are involved in processing payments.
These services enable customers to purchase goods and services. They also enable merchants to receive payments from customer accounts, to provide refunds, and to void transactions.

Authorization

An authorization confirms that a payment card account holds enough funds to pay for a purchase. Authorizations can be made online or offline.

Micropayment Authorization

Micropayments are payments for less than one unit in the transaction’s currency.
Cybersource
 does not support micropayment authorizations for
UATP
.

Online Authorization

Online authorizations provide immediate confirmation of funds availability. The customer's financial institution also reduces the amount of credit available in the customer's account, setting aside the authorized funds for the merchant to capture at a later time. Authorizations for most payment cards are processed online. Typically, it is safe to start fulfilling the order when you receive an authorization confirmation.
An
 online authorization confirmation and the subsequent hold on funds expire after a specific length of time. Therefore it is important to capture funds in a timely manner. The issuing bank sets the expiration time interval, but most authorizations expire within
5 to
 7 days.
The issuing bank does not inform
Cybersource
 when an authorization confirmation expires. By default, the authorization information for each transaction remains in the
Cybersource
 database for 180 days after the authorization date. To capture an authorization that expired with the issuing bank, you can resubmit the authorization request.

Offline Authorization

Online transactions require an internet connection. In situations where the internet is not available, for example, due to an outage, merchants can continue to take credit card payments using offline transactions. An offline authorization is an authorization request for which you do not receive an immediate confirmation about the availability of funds.
Offline authorizations have a higher level of risk than online transactions because they do not confirm funds availability or set aside the funds for later capture. Further, it can take up to 5 days to receive payment confirmations for offline transactions. To mitigate this risk, merchants may choose to fulfill orders only after receiving payment confirmation.

Authorization Workflow

This image and description show the authorization workflow:
  1. The customer purchases goods or services from the merchant using a payment card.
  2. You send an authorization request over secure internet connection to
    Cybersource
    . When the customer buys a digitally delivered product or service, you can request both the authorization and the capture at the same time. When the customer buys a physically fulfilled product, do not request the capture until you ship the product.
  3. Cybersource
     validates the order information then contacts your payment processor and requests authorization.
  4. The processor sends the transaction to the payment card company, which routes it to the issuing bank for the customer's payment card. Some card companies, including Discover
    and American Express
    , act as their own issuing banks.
  5. The issuing bank approves or declines the request.
    • If funds are available, the issuing bank reserves the amount of the authorization request and returns an authorization approval to
      Cybersource
      .
    • If the issuing bank denies the request, it returns an authorization denial to
      Cybersource
      .
  6. Cybersource
     runs its own tests then tells you whether the authorization succeeded.

Sale

A sale is a bundled authorization and capture. Some processors and acquirers require a sale transaction instead of using separate authorization and capture requests. For other processors and acquirers, you can request a sale instead of a separate authorization and capture when you provide the goods or services immediately after taking an order.
There are two types of sale processing: dual-message processing and single-message processing.

Dual-Message Processing

Dual-message processing is a two-step process. The authorization is processed first. If the authorization is successful, the capture is processed immediately afterward. The response includes the authorization and the capture information. If the authorization is declined, the capture is not processed, and the response message includes only the authorization information.

Capture

A capture is a follow-on transaction to an authorization. It is used to transfer the authorized funds from the customer's account to the merchant account. To link the authorization transaction to the capture transaction, you include a request ID in your capture request. This request ID is returned to you in the authorization response.
Captures are typically not performed in real time. They are placed in a batch file and sent to the processor, and the processor settles all of the captures at one time. In most cases, these batch files are sent and processed outside of the merchant's business hours. It usually takes 2 to 4 days for the acquiring financial institution to deposit the funds into the merchant account.
When fulfilling only part of a customer’s order, do not capture the full amount of the authorization. Capture only the cost of the delivered items. When you deliver the remaining items, request a new authorization, and then capture the new authorization.
IMPORTANT
It is not possible to perform a capture if a transaction is in a review state, which can occur if you use a fraud management service. You must accept the transaction prior to capture. For more information, see the fraud management documentation in
the
Business Center
.

Capture Workflow

The capture workflow begins when you send a request for a capture.
  1. The merchant sends a request for a capture to the
    Cybersource
     gateway.
  2. For online captures,
    Cybersource
     validates the order information then sends an online capture to the payment processor.
    For offline captures,
    Cybersource
     stores the capture request in a batch file and sends the batch file to the payment processor after midnight.
  3. The processor validates the request and forwards it to the issuing bank.
  4. The issuing bank transfers funds to the acquiring bank.
IMPORTANT
The payment processor does not notify
Cybersource
 that the money has been transferred. To ensure that all captures are processed correctly, you should reconcile your capture requests with the capture reports from your processor.

Refund

Refunds are payment refunds from a merchant to the cardholder after a cardholder pays for a product or service and that payment is captured by the merchant. When a refund request is successful, the issuer transfers funds from the merchant bank (acquirer) account to the customer's account. It typically takes 2 to 4 days for the acquirer to transfer funds from your merchant account.
There are two types of refunds: a
follow-on refund
 that is linked to an original capture or sale, and a
stand-alone credit
 that is not linked to an original capture or sale.
WARNING
You should carefully control access to your
refund and
 credit services. Do not request this service directly from your customer interface. Instead, incorporate this service as part of your customer service process. This process reduces the potential for fraudulent transactions.

Follow-on Refund

Refunds, also known as
follow-on refunds
,
 use the capture request ID to link the refund to the original transaction.
This request ID is returned during the capture request (also known as a
settlement
) and is used in all subsequent refunds associated with the original capture.
 The request ID links the transaction to the customer’s billing and account information, so you are not required to include those fields in the
refund
 request.
When you combine a request for a
refund
 with a request for another service, such as the tax calculation service, you must provide the customer’s billing and account information.
Unless otherwise specified,
refunds
 must be requested within 180 days of a settlement. You can request multiple follow-on
refunds
 against a single capture or sale transaction as long as the total amount does not exceed the original purchase amount. To perform multiple follow-on
refunds
, use the same request ID in each request.

Stand-Alone Credits

Stand-alone credits are not connected to an original transaction. Stand-alone credits do not have a time restriction, and they can be used to issue refunds more than 180 days after a transaction settlement.

Credit Workflow

This workflow applies to follow-on credits, also known as refunds, and stand-alone credits. It begins when you send a request for a credit.
Credits do not happen in real time. All of the credit requests for a day are typically placed in a file and sent to the processor as a single
batch
 transaction. In most cases, the batch transaction is settled overnight.
  1. The merchant sends the credit request to
    Cybersource
    .
  2. For online credits,
    Cybersource
     validates the order information then sends the request to the payment processor.
    For offline credits,
    Cybersource
     stores the request in a batch file and sends the batch file to the payment processor after midnight.
  3. The processor validates the request and forwards it to the acquiring bank.
  4. The acquiring bank transfers funds to the issuing bank.
IMPORTANT
Not all processors support stand-alone credits.

Void

A void cancels a capture or credit request that you submitted to
Cybersource
 but has not already been submitted to your processor. Capture and credit requests are usually submitted to your processor once a day, so your window for successfully voiding a capture or credit request is small. A void request is declined when the capture or credit request has already been sent to the processor.
After a void is processed, you cannot credit or capture the funds. You must perform a new transaction to capture or credit the funds. Further, when you void a capture, a hold remains on the authorized funds. If you are not going to re-capture the authorization,
and if your processor supports authorization reversal after void (ARAV),
 you should request an authorization reversal to release the hold on the unused funds.
A void uses the capture or credit request ID to link the transactions. The authorization request ID is used to look up the customer’s billing and account information, so there is no need to include those fields in the void request. You cannot perform a follow-on credit against a capture that has been voided.

Testing the Payment Services

To ensure that requests are processed correctly, you must test the basic success and error conditions for each service you plan to use.

Requirements for Testing

Before you can test, contact customer support to activate the credit card services and configure your account for testing. You must also contact your processor to set up your processor account.
IMPORTANT
When building your connection to the
Cybersource
 payment gateway, ensure that you have implemented controls to prevent card testing or card enumeration attacks on your platform.
For more information, see the best practices guide.
When we detect suspicious transaction activity associated with your merchant ID, including a card testing or card enumeration attack,
Cybersource
 reserves the right to enable fraud management tools on your behalf in order to mitigate the attack. The fraud team might also implement internal controls to mitigate attack activity. These controls block traffic that is perceived as fraudulent. Additionally, if you are using one of our fraud tools and experience a significant attack, our internal team might modify or add rules to your configuration to help prevent the attack and minimize the threat to our infrastructure. However, any actions taken by
Cybersource
 would not replace the need for you to follow industry standard best practices to protect your systems, servers, and platforms.
Follow these requirements when you test your system:
  • Use your regular merchant ID.
  • Use a real combination for the city, state, and postal code.
  • Use a real combination for the area code and telephone number.
  • Use a nonexistent account and domain name for the customer’s email address.
  • REST API test endpoint:
    POST
    https://apitest.cybersource.com
    /pts/v2/payments

Test Card Numbers

Use these payment card numbers to test the authorization, capture, and credit services. Remove the spaces from the test card numbers when sending them to the test system. Do not use real payment card numbers. To test card types that are not included in the list, use an account number that is in the card’s BIN range. For best results, try each test with a different service request and with different test payment card numbers.
IMPORTANT
The test card numbers that are provided are formatted with Xs for zeroes in the card number. When testing with these card numbers, remove the spaces and replace each X with a 0 (zero).
  • American Express—3782 8224 631X XX5
  • Discover—6X11 1111 1111 1117
  • JCB—3566 1111 1111 1113
  • Maestro (International)
    • 5X33 9619 89X9 17
    • 5868 2416 0825 5333 38
  • Maestro (UK Domestic)—the issue number is not required for Maestro (UK Domestic) transactions.
    • 6759 4111 XXXX XXX8
    • 6759 56XX 45XX 5727 054
    • 5641 8211 1116 6669
  • Mastercard
    • 2222 42XX XXXX 1113
    • 2222 63XX XXXX 1125
    • 5555 5555 5555 4444
  • UATP (CVV not required)
    • 1354 1234 5678 911
    • 1485 1234 5678 9X5
  • Visa—4111 1111 1111 1111

Using Amounts to Simulate Errors

You can simulate error messages by requesting authorization, capture, or credit services with specific amounts that trigger the error messages. These triggers work only on the test server, not on the production server.
Each payment processor uses its own error messages.
For more information, see: REST API Testing Guide

Test American Express Card Verification

Before using CVN with American Express, it is strongly recommended that you follow these steps:
  1. Contact customer support to have your account configured for CVN. Until you do this, you will receive a
    1
     in the
    processorInformation.cardVerification.resultCode
     response field.
  2. Test your system in production using a small currency amount, such as one currency unit. Instead of using the test account numbers, use a real payment card account number, and send an incorrect CVN in the request for authorization. The card should be refused and the request declined.

Standard Payment Processing

This section shows you how to process various authorization, capture, credit, and sales transactions.

Basic Authorization

This section provides the information you need in order to process a basic authorization.
All supported card types can process authorizations.

Endpoint

Production:
POST
https://api.cybersource.com
/pts/v2/payments
Test:
POST
https://apitest.cybersource.com
/pts/v2/payments

Declined Authorization

If an authorization is declined, you can use response categories to help you decide whether to retry or block a declined transaction. These response fields provide additional information:
  • paymentInsightsInformation.responseInsights.category
  • paymentInsightsInformation.responseInsights.categoryCode
Category codes have possible values (such as
01
) each of which corresponds to a category that contains a description.
You cannot retry this category code and category:
  • 01 ISSUER_WILL_NEVER_APPROVE
For these values, you can retry the transaction a maximum of 15 times over a period of 30 days:
  • 02 ISSUER_CANNOT_APPROVE_AT_THIS_TIME
  • 03 ISSUER_CANNOT_APPROVE_WITH_THESE_DETAILS
    : Data quality issue. Revalidate data prior to retrying the transaction.
  • 04 GENERIC_ERROR
  • 97 PAYMENT_INSIGHTS_INTERNAL_ERROR
  • 98 OTHERS
  • 99 PAYMENT_INSIGHTS_RESPONSE_CATEGORY_MATCH_NOT_FOUND

REST Example: Processing a Basic Authorization

Request
{
    "orderInformation": {
        "billTo": {
            "country": "US",
            "lastName": "Kim",
            "address1": "201 S. Division St.",
            "postalCode": "48104-2201",
            "locality": "Ann Arbor",
            "administrativeArea": "MI",
            "firstName": "Kyong-Jin",
            "email": "
test@cybs.com
"
        },
        "amountDetails": {
            "totalAmount": "100.00",
            "currency": "usd"
        }
    },
    "paymentInformation": {
        "card": {
            "expirationYear": "2031",
            "number": "4111111111111111",
            "expirationMonth": "12",
            "type": "001"
        }
    }
}
Response to a Successful Request
{
  "_links" : {
    "authReversal" : {
      "method" : "POST",
      "href" : "/pts/v2/payments/6461731521426399003473/reversals"
    },
    "self" : {
      "method" : "GET",
      "href" : "/pts/v2/payments/6461731521426399003473"
    },
    "capture" : {
      "method" : "POST",
      "href" : "/pts/v2/payments/6461731521426399003473/captures"
    }
  },
  "clientReferenceInformation" : {
    "code" : "1646173152047"
  },
  "id" : "6461731521426399003473",
  "orderInformation" : {
    "amountDetails" : {
      "authorizedAmount" : "100.00",
      "currency" : "usd"
    }
  },
  "paymentAccountInformation" : {
    "card" : {
      "type" : "001"
    }
  },
  "paymentInformation" : {
    "tokenizedCard" : {
      "type" : "001"
    },
    "card" : {
      "type" : "001"
    }
  },
 "paymentInsightsInformation" : {
    "responseInsights" : {
      "categoryCode" : "01"
    }
  },
  "processorInformation" : {
    "systemTraceAuditNumber" : "862481",
    "approvalCode" : "831000",
    "merchantAdvice" : {
      "code" : "01",
      "codeRaw" : "M001"
    },
    "responseDetails" : "ABC",
    "networkTransactionId" : "016153570198200",
    "consumerAuthenticationResponse" : {
      "code" : "2",
      "codeRaw" : "2"
    },
    "transactionId" : "016153570198200",
    "responseCode" : "00",
    "avs" : {
      "code" : "Y",
      "codeRaw" : "Y"
    }
  },
  "reconciliationId" : "6461731521426399003473",
  "status" : "AUTHORIZED",
  "submitTimeUtc" : "2022-03-01T22:19:12Z"
}
Response to a Declined Request
{
  "clientReferenceInformation": {
    "code": "TC50171_3"
  },
  "errorInformation": {
    "reason": "PROCESSOR_ERROR",
    "message": "Invalid account"
  },
  "id": "6583553837826789303954",

  "paymentInsightsInformation": {
    "responseInsights": {
      "categoryCode": "01",
      "category": "ISSUER_WILL_NEVER_APPROVE"
    }
  },

  "pointOfSaleInformation": {
    "amexCapnData": "1009S0600100"
  },
  "processorInformation": {
    "systemTraceAuditNumber": "004544",
    "merchantNumber": "1231231222",
    "networkTransactionId": "431736869536459",
    "transactionId": "431736869536459",
   "responseCode": "111",
    "avs": {
      "code": "Y",
      "codeRaw": "Y"
    }
  },
  "status": "DECLINED"
}

Authorization with Line Items

This section shows you how to process an authorization with line items.
The main difference between a basic authorization and an authorization that includes line items is that the
orderInformation.amountDetails.totalAmount
 field, which is included in a basic authorization, is substituted with one or more line items that are included in
a
lineItem[]
 array
.

Fields Specific to this Use Case

These
fields
 are required for each line item that you use:
orderInformation.lineItems[].unitPrice
orderInformation.lineItems[].quantity
orderInformation.lineItems[].productCode
orderInformation.lineItems[].productSku
Optional when
item_#_productCode
 is set to
default
,
shipping_only
,
handling_only
, or
shipping_and_handling
orderInformation.lineItems[].productName
Optional when
item_#_productCode
 is set to
default
,
shipping_only
,
handling_only
, or
shipping_and_handling
At a minimum, you must include the
orderInformation.lineItems[].unitPrice
 field in order to include a line item in an authorization. When this field is the only field included in the authorization, the system sets:
  • orderInformation.lineItems[].productCode
    :
    default
  • orderInformation.lineItems[].quantity
    :
    1
For example, these three line items are valid.
"orderInformation": {
  "lineItems": [
    {
      "unitPrice": "10.00"
    },
    {
      "unitPrice": "5.99",
      "quantity": "3",
      "productCode": "shipping_only"
    },
    {
      "unitPrice": "29.99",
      "quantity": "3",
      "productCode": "electronic_good",
      "productSku": "12384569",
      "productName": "receiver"
    }
  ]
}

Endpoint

Production:
POST
https://api.cybersource.com
/pts/v2/payments
Test:
POST
https://apitest.cybersource.com
/pts/v2/payments

REST Example: Processing an Authorization with Line Items

Request
{
  "currencyConversion": {
    "indicator": "Y"
  },
  "paymentInformation": {
    "card": {
      "number": "4111111111111111",
      "expirationMonth": "12",
      "expirationYear": "2031"
    }
  },
  "orderInformation": {
    "amountDetails": {
      "currency": "USD",
      "exchangeRate": ".91",
      "originalAmount": "107.33",
      "originalCurrency": "eur"
    },
    "billTo": {
      "firstName": "John",
      "lastName": "Doe",
      "address1": "1 Market St",
      "locality": "san francisco",
      "administrativeArea": "CA",
      "postalCode": "94105",
      "country": "US",
      "email": "
test@cybs.com
"
    },
    "lineItems": [
      {
        "unitPrice": "10.00"
      },
      {
        "unitPrice": "5.99",
        "quantity": "3",
        "productCode": "shipping_only"
      },
      {
        "unitPrice": "29.99",
        "quantity": "3",
        "productCode": "electronic_good",
        "productSku": "12384569",
        "productName": "receiver"
      }
    ]
  }
}
Response to a Successful Request
{
  "_links": {
    "authReversal": {
      "method": "POST",
      "href": "/pts/v2/payments/6482385519226028804003/reversals"
    },
    "self": {
      "method": "GET",
      "href": "/pts/v2/payments/6482385519226028804003"
    },
    "capture": {
      "method": "POST",
      "href": "/pts/v2/payments/6482385519226028804003/captures"
    }
  },
  "clientReferenceInformation": {
    "code": "1648238551902"
  },
  "id": "6482385519226028804003",
  "orderInformation": {
    "amountDetails": {
      "authorizedAmount": "117.94",
      "currency": "USD"
    }
  },
  "paymentAccountInformation": {
    "card": {
      "type": "001"
    }
  },
  "paymentInformation": {
    "tokenizedCard": {
      "type": "001"
    },
    "card": {
      "type": "001"
    }
  },
  "processorInformation": {
    "systemTraceAuditNumber": "191521",
    "approvalCode": "831000",
    "merchantAdvice": {
      "code": "01",
      "codeRaw": "M001"
    },
    "responseDetails": "ABC",
    "networkTransactionId": "016153570198200",
    "consumerAuthenticationResponse": {
      "code": "2",
      "codeRaw": "2"
    },
    "transactionId": "016153570198200",
    "responseCode": "00",
    "avs": {
      "code": "Y",
      "codeRaw": "Y"
    }
  },
  "reconciliationId": "6482385519226028804003",
  "status": "AUTHORIZED",
  "submitTimeUtc": "2022-03-25T20:02:32Z"
}

Sale

This section provides the information you need in order to process a sale transaction.
A sale combines an authorization and a capture into a single transaction.

Endpoint

Production:
POST
https://api.cybersource.com
/pts/v2/payments
Test:
POST
https://apitest.cybersource.com
/pts/v2/payments

REST Example: Sale

Request
{
  "processingInformation": {
    "capture": true
  },
  "orderInformation" : {
    "billTo" : {
    "country" : "US",
    "lastName" : "VDP",
    "address1" : "201 S. Division St.",
    "postalCode" : "48104-2201",
    "locality" : "Ann Arbor",
    "administrativeArea" : "MI",
    "firstName" : "RTS",
    "email" : "
test@cybs.com
"
  },
    "amountDetails" : {
      "totalAmount" : "100.00",
      "currency" : "usd"
     }
   },
  "paymentInformation" : {
    "card" : {
      "expirationYear" : "2031",
      "number" : "4111111111111111",
      "expirationMonth" : "12",
      "type" : "001
    }
  }
}
Response to a Successful Request
Most processors do not return all of the fields that are shown in this example.
{
  "_links" : {
    "void" : {
      "method" : "POST",
      "href" : "/pts/v2/payments/6485004068966546103093/voids"
    },
    "self" : {
      "method" : "GET",
      "href" : "/pts/v2/payments/6485004068966546103093"
    }
  },
  "clientReferenceInformation" : {
    "code" : "RTS-Auth"
  },
  "id" : "6485004068966546103093",
  "orderInformation" : {
    "amountDetails" : {
      "totalAmount" : "100.00",
      "authorizedAmount" : "100.00",
      "currency" : "usd"
    }
  },
  "paymentAccountInformation" : {
    "card" : {
      "type" : "001"
    }
  },
  "paymentInformation" : {
    "tokenizedCard" : {
      "type" : "001"
    },
    "card" : {
      "type" : "001"
    }
  },
  "processorInformation" : {
    "systemTraceAuditNumber" : "841109",
    "approvalCode" : "831000",
    "merchantAdvice" : {
      "code" : "01",
      "codeRaw" : "M001"
    },
    "responseDetails" : "ABC",
    "networkTransactionId" : "016153570198200",
    "retrievalReferenceNumber" : "208720841109",
    "consumerAuthenticationResponse" : {
      "code" : "2",
      "codeRaw" : "2"
    },
    "transactionId" : "016153570198200",
    "responseCode" : "00",
    "avs" : {
      "code" : "Y",
      "codeRaw" : "Y"
    }
  },
  "reconciliationId" : "6485004068966546103093",
  "status" : "AUTHORIZED",
  "submitTimeUtc" : "2022-03-28T20:46:47Z"
}

Capture

This section describes how to capture an authorized transaction.

Endpoint

Production:
POST
https://api.cybersource.com
/pts/v2/payments/
{id}
/captures
Test:
POST
https://apitest.cybersource.com
/pts/v2/payments/
{id}
/captures
The
{id}
 is the transaction ID returned in the authorization response.

Required Fields for Capturing an Authorization

This field value maps from the original authorization, sale, or credit transaction.

REST Example: Capturing an Authorization

Request
{
    "clientReferenceInformation": {
        "code": "ABC123"
    },
    "orderInformation": {
        "amountDetails": {
            "totalAmount": "100.00",
            "currency": "EUR"
    }
}
Response to a Successful Request
{
    "_links": {
        "void": {
            "method": "POST",
            "href": "/pts/v2/captures/6662994431376681303954/voids"
        },
        "self": {
            "method": "GET",
            "href": "/pts/v2/captures/6662994431376681303954"
        }
    },
    "clientReferenceInformation": {
        "code": "1666299443215"
    },
    "id": "6662994431376681303954",
    "orderInformation": {
        "amountDetails": {
            "totalAmount": "100.00",
            "currency": "EUR"
        }
    },
    "reconciliationId": "66535942B9CGT52U",
    "status": "PENDING",
    "submitTimeUtc": "2022-10-20T20:57:23Z"
}

Follow-On
Refund

This section provides the information you need in order to process a follow-on
refund
, which is linked to a capture or sale. You must request a follow-on
refund
 within 180 days of the authorization or sale.

Endpoint

Production:
POST
https://api.cybersource.com
/pts/v2/payments/
{id}
/refunds
Test:
POST
https://apitest.cybersource.com
/pts/v2/payments/
{id}
/refunds
The
{id}
 is the transaction ID returned in the capture or sale response.

REST Example: Processing a Refund

Request
{
    "orderInformation": {
        "amountDetails": {
            "totalAmount": "100.00",
            "currency": "EUR"
        }
    }
}
Response to a Successful Request
{
    "_links": {
        "void": {
            "method": "POST",
            "href": "/pts/v2/credits/6699964581696622603955/voids"
        },
        "self": {
            "method": "GET",
            "href": "/pts/v2/credits/6699964581696622603955"
        }
    },
    "clientReferenceInformation": {
        "code": "1669996458298"
    },
    "creditAmountDetails": {
        "currency": "eur",
        "creditAmount": "100.00"
    },
    "id": "6699964581696622603955",
    "orderInformation": {
        "amountDetails": {
            "currency": "EUR"
        }
    },
    "paymentAccountInformation": {
        "card": {
            "type": "001"
        }
    },
    "paymentInformation": {
        "tokenizedCard": {
            "type": "001"
        },
        "card": {
            "type": "001"
        }
    },
    "processorInformation": {
        "approvalCode": "888888",
        "networkTransactionId": "016153570198200",
        "responseCode": "100"
    },
    "reconciliationId": "61873329OAILG3Q6",
    "status": "PENDING",
    "submitTimeUtc": "2022-12-02T15:54:18Z"
}

Stand-Alone Credit

This section shows you how to process a credit, which is not linked to a capture or sale. There is no time limit for requesting a credit.

Endpoint

Production:
POST
https://api.cybersource.com
/pts/v2/credits/
Test:
POST
https://apitest.cybersource.com
/pts/v2/credits/

REST Example: Processing a Stand-Alone Credit

Request
{
  "orderInformation" : {
    "billTo" : {
      "country" : "US",
      "lastName" : "Kim",
      "address1" : "201 S. Division St.",
      "postalCode" : "48104-2201",
      "locality" : "Ann Arbor",
      "administrativeArea" : "MI",
      "firstName" : "Kyong-Jin",
      "email" : "
test@cybs.com
"
    },
    "amountDetails" : {
      "totalAmount" : "100.00",
      "currency" : "eur"
    }
  },
  "paymentInformation" : {
    "card" : {
      "expirationYear" : "2031",
      "number" : "4111111111111111",
      "expirationMonth" : "12"
    }
  }
}
Response to a Successful Request
{
    "_links": {
        "void": {
            "method": "POST",
            "href": "/pts/v2/credits/6663069906146706403954/voids"
        },
        "self": {
            "method": "GET",
            "href": "/pts/v2/credits/6663069906146706403954"
        }
    },
    "clientReferenceInformation": {
        "code": "1666306990717"
    },
    "creditAmountDetails": {
        "currency": "eur",
        "creditAmount": "100.00"
    },
    "id": "6663069906146706403954",
    "orderInformation": {
        "amountDetails": {
            "currency": "eur"
        }
    },
    "paymentAccountInformation": {
        "card": {
            "type": "001"
        }
    },
    "paymentInformation": {
        "tokenizedCard": {
            "type": "001"
        },
        "card": {
            "type": "001"
        }
    },
    "processorInformation": {
        "approvalCode": "888888",
        "networkTransactionId": "016153570198200",
        "responseCode": "100"
    },
    "reconciliationId": "66490108K9CLFJPN",
    "status": "PENDING",
    "submitTimeUtc": "2022-10-20T23:03:10Z"
}

Void for a Capture or Credit

This section describes how to void a capture or credit that was submitted but not yet processed by the processor.

Endpoints

Void a Capture
Production:
POST
https://api.cybersource.com
/pts/v2/captures/
{id}
/voids
Test:
POST
https://apitest.cybersource.com
/pts/v2/captures/
{id}
/voids
Void a Credit
Production:
POST
https://api.cybersource.com
/pts/v2/credits/
{id}
/voids
Test:
POST
https://apitest.cybersource.com
/pts/v2/credits/
{id}
/voids
The
{id}
 is the transaction ID returned during the capture or credit response.

Required Fields for Voiding a Capture or Credit

Including this field is recommended, but not required.

REST Example: Voiding a Capture or Credit

Request
{
    "clientReferenceInformation": {
        "code": "test123"
    }
}
Response to a Successful Request
{
    "_links": {
        "self": {
            "method": "GET",
            "href": "/pts/v2/voids/6541933390746728203005"
        }
    },
    "clientReferenceInformation": {
        "code": "1654193339056"
    },
    "id": "6541933390746728203005",
    "orderInformation": {
        "amountDetails": {
        "currency": "USD"
        }
    },
    "status": "VOIDED",
    "submitTimeUtc": "2022-06-02T18:08:59Z",
    "voidAmountDetails": {
        "currency": "usd",
        "voidAmount": "100.00"
    }
}