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
Simple Order 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:
An
Important
 statement contains information essential to successfully completing a task or learning a concept.
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

25.07.01

Extensive
eftpos
 updates
Added:
Updated:
Removed:
  • Content in the Payment Services section about authorizations.
  • Content about dual message processing.
  • Content about simulating errors.
  • Content about American Express.
  • Content about refunds.
  • Content about timeout authorization reversals.

25.05.01

This revision contains only editorial changes and no technical updates.

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.

25.02

This revision contains only editorial changes and no technical updates.

25.01

Added a testing section. See Testing the Payment Services.

24.02

This revision contains only editorial changes and no technical updates.

24.01

Initial Release.

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.

eftpos
 Australia

eftpos
 is Australia’s domestic debit card payments network.
eftpos
 primarily offers co-badged dual network debit cards with international networks like Visa and Mastercard. These dual network debit cards can be used to make transactions through eftpos or the Visa/Mastercard networks.
eftpos
 also has proprietary single network debit cards that are used only for card present transactions.

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 payment cards. 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, card-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 your acquirer to charge 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 fraudulant 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 acquiring financial institutions and issuing financial institutions. They also develop industry standards, support their brands, and establish fees for acquiring institutions.
Some payment networks, such as Visa, Mastercard, and UnionPay International, are trade associations that do not issue cards. Issuers are members of these associations, and they issue cards under license from the association.

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.

Card Types

eftpos
 supports these two types of cards:
  • Proprietary single network debit cards: These cards function exclusively within the domestic
    eftpos
     network for facilitating financial transactions.
  • Co-badged dual network debit cards: These cards allow domestic payments to be processed by either
    eftpos
     or one of the international networks like Mastercard and Visa, offering greater flexibility and convenience.

Transaction Types

This topic provides information about transaction types that are supported by your processor, such as card-present, card-not-present, and international transactions.
Currently,
eftpos
 supports only card-not-present transactions.

Card-Not-Present Transactions

When a customer provides a card number, but the card and the customer are not physically present at the merchant's location, the purchase is known as a
card-not-present transaction
.
eftpos
 card-not-present transactions can be initiated either by the cardholder or the merchant:
  • Cardholder-Initiated Transactions: These transactions can be authenticated using either the Cardholder Verification Value (CVV) or
    3-D Secure
    . Currently,
    3-D Secure
     2.1.0 is supported for
    eftpos
     .
  • Merchant-Initiated Transactions: These transactions can be authenticated using the CVV.
    3-D Secure
     authentication is not supported.
Online transaction security is bolstered by mechanisms such as CVV and
3-D Secure
, which play crucial roles in verifying cardholder identity and preventing fraudulent activities. The Card Verification Value(CVV) is a three- or four-digit number found on the back of credit or debit cards, providing an additional layer of security by confirming that the person making the transaction physically possesses the card. Meanwhile,
3-D Secure
 is a security protocol that adds an extra layer of authentication to online transactions. It typically involves sending a one-time password (OTP) to the cardholder's registered mobile device, ensuring that only the legitimate cardholder can authorize the transaction.
Currently,
3-D Secure
 authentication is supported only for cardholder-initiated transactions and version 2.1.0 of the
3-D Secure
 protocol.

Payment Services

Various services are involved in processing
eftpos
 cards.
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.

Sales

A sale is a bundled authorization and capture. eftpos uses single-message format. Single-message processing treats the authorization and capture as a single transaction. The request is treated as a full financial transaction.
There are several types of sale transactions.
  • Single payment: The customer provides their card information to a merchant for a one-time purchase. This card information is not saved, but the consumer can store their card information after the transaction. Only the cardholder can initiate a single payment.
  • First Pay As You Go (PAYG): The customer registers their card details with the merchant to use for the first payment. This type of sale can include ad hoc transactions like order-ahead apps or transactions with variable frequency and fixed amounts, such as automatic top-ups for road tolls. The initial PAYG transactions can be initiated by the merchant or the cardholder.
  • Subsequent PAYG: After the initial PAYG transaction occurs, subsequent payments are processed as the cardholder continues buying goods and services from the merchant.
  • First Fixed-Frequency Recurring: The cardholder agrees to a schedule of payments at regular intervals between the consumer and the merchant using the stored payment information. The payment amount can be fixed (for example, a gym membership) or variable (for example, a consumption-based utility bill). In the current implementation, only recurring transactions with a fixed payment amount are supported. The first recurring payment can be initiated by the cardholder or the merchant.
  • Subsequent Fixed-Frequency Recurring: The merchant uses the cardholder payment information to initiate payments at the scheduled intervals. The transaction amounts can be fixed or variable and the number of transactions the merchant may initiate are unlimited. In the current implementation, only recurring transactions with a fixed payment amount are supported. All subsequent recurring payments are merchant initiated.
  • First Installment: The cardholder provides payment information and agrees to the number of payments, transaction amount, and the frequency of payments before the first transaction. The initial installment payments can be initiated by the cardholder or the merchant.
  • Subsequent Installment: The cardholder provides payment information and agrees to the number of payments, transaction amount, and the frequency of payments before the first transaction. Subsequent installment payments are initiated by the merchant.

Sales with
3-D Secure

3-D Secure
 helps to minimize costly fraudulent transactions by adding an extra layer of protection to the payment process. Payer Authentication uses the
3-D Secure
 protocol in online transactions to verify that payment is coming from the actual cardholder. Most transactions can be authenticated without the customer being aware of the process, but higher-risk transactions might require an exchange of one-time passwords (OTPs) during authentication. This authentication of the payer before the transaction, benefits the merchant by shifting chargeback liability from the merchant to the card issuer.
The authentication and authorization transactions can be bundled together or can occur sequentially, for example, authentication followed by authorization. Two types of bundled scenarios are possible:
  • Combining Check Enrollment with Sale: When a customer is authenticated without a challenge, the transaction can be authorized in the same request or in a separate authorization request. Whether authorization occurs in the same request or a separate request, the values from the check enrollment response must be passed to the authorization request to qualify for a liability shift.
  • Combining Validation with Sale: When a customer is authenticated after a challenge, the transaction can be authorized in the same request or in a separate authorization request. Whether authorization is combined with validation or occurs in a separate request, the values from the validation response must be passed to the authorization request to qualify for a liability shift to the issuing bank.
The current solution supports the
3-D Secure
 2.1.0 specification. All customer-initiated card-not-present sales transactions mentioned in point 1 can be authenticated with
3-D Secure
. Currently, merchant-initiated
3-D Secure
 transactions are not supported for
eftpos
 .
These ECI values support
3-D Secure
 transactions:
ECI Values Used for
eftpos
ECI Value
Description
oci (
05
)
Authentication was successful for the
eftpos
 card.
oci_attempted (
06
)
Authentication was attempted but not successful for the
eftpos
 card.
oci_failure (
07
)
Authentication was unsuccessful for the
eftpos
 card.
For more information about payer authentication, see the
Payer Authentication Developer Guide
.

Credits

Credits 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 credit 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.
You should carefully control access to the credit service. 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.
There are two basic types of credits:
follow-on credits
 and stand-alone credits.

Follow-On Credits

Refunds, also known as
follow-on refunds
, use the sale request ID to link the refund to a specific transaction. 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 credit request.
Unless otherwise specified, refunds must be requested within 180 days of a settlement. You can request multiple refunds against a single
purchase transaction as long as the total amount does not exceed the original purchase amount.
 To perform multiple 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

The credit workflow begins when you send a request for a credit.
  1. The merchant sends a request for a credit to
    Cybersource
    .
  2. For online credits,
    Cybersource
     validates the order information then sends an online credit to the payment processor.
  3. The processor validates the request and forwards it to the acquiring bank.
  4. The acquiring bank transfers funds to the issuing bank.

Voids

A void cancels a capture or credit request that was submitted but not yet processed by the processor.
Capture and credit requests are usually submitted once a day. 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.
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.
  • Simple Order API test server:
    https://ics2wstesta.ic3.com/commerce/1.x/transactionProcessor

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.
The test card numbers that are provided are formatted with Xs for zeroes in the card number. When testing with the card numbers, replace the Xs with a 0 (zero).
  • eftpos
     Visa co-badged card
    • 4434 X2XX XXXX XXX6
    • 4X65 87XX XXXX XXXX
    • 494X 53XX XXXX XXX1
  • eftpos
     Mastercard co-badged card
    • 5163 6629 551X 5217
  • eftpos
     sole proprietary card
    • 5X21 18XX XXXX XXX4
    • 5X1X X7XX XXXX XXXX
    • 5X18 X3XX XXXX XXX6
Test card numbers for testing
3-D Secure
 scenarios are available. For more information, go to the
Payer Authentication Developer Guide
.

Standard Payment Processing

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

Account Verification Request

This section provides the information that you need in order to process an account verification request.
Authorizing a payment for an account verification request shows whether a payment card account is valid and whether the card is lost or stolen. You cannot capture an account verification request.

Endpoint

Set the
ccAuthService_run
 field to
true
.
Send the request to
https://ics2ws.ic3.com/commerce/1.x/transactionProcessor
.

Required Fields for Processing
an Account Verification Request

Use these required fields for processing
an account verification request
.
billTo_city
billTo_country
billTo_email
billTo_firstName
billTo_lastName
billTo_postalCode
billTo_state
billTo_street1
card_accountNumber
card_expirationMonth
card_expirationYear
ccAuthService_run
Set the value to
true
.
merchantID
merchantReferenceCode
purchaseTotals_currency
purchaseTotals_grandTotalAmount

Simple Order Example: Processing a Zero Amount Authorization

Request
billTo_city=Sao Paulo
billTo_country=BR

billTo_firstname=Julia
billTo_lastname=Fernandez
billTo_postalCode=01310-000
billTo_state=SP
billTo_street1=R. Augusta
card_accountNumber=41111111XXXXXXXX
card_expirationMonth=12
card_expirationYear=2023
ccAuthService_run=true
merchant_id=MID23
merchant_referenceCode=Merchant_REF
purchaseTotals_currency=mxn
purchaseTotals_grandTotalAmount=0
Response to a Successful Request
additional_processor_response=e1cdcafc-cdbb-4ef7-8788-a1234e844805
request_id=6461515866500167772420
decision=ACCEPT
reasonCode=100
merchantReferenceCode=Merchant_REF
purchaseTotals_currency=mxn
cardCategory=FccAuthService_reconciliationID=ZUDCXJO8KZRFXQJJ
ccAuthReply_amount=0
ccAuthReply_avsCode=5
ccAuthReply_authorizationCode=570110
ccAuthReply_processorResponse=1
ccAuthReply_authorizedDateTime=2022-03-01T161947Z
ccAuthReply_paymentNetworkTransactionID=111222

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

Set the
ccAuthService_run
 field to
true
, and the
ccCaptureService_run
 field to
true
.
Send the request to
https://ics2ws.ic3.com/commerce/1.x/transactionProcessor
.

Required Fields for Processing a Sale

billTo_city
billTo_country
billTo_email
billTo_firstName
billTo_lastName
billTo_postalCode
billTo_state
billTo_street1
card_accountNumber
card_cardType
card_expirationMonth
card_expirationYear
ccAuthService_commerceIndicator
ccAuthService_run
Set the value to
true
.
ccCaptureService_run
Set the value to
true
.
merchantID
purchaseTotals_currency
purchaseTotals_grandTotalAmount

Additional Required Fields for Specific Sales Transactions

Some types of sales transactions require additional fields. The need for these fields and their values depend upon the type of transaction, whether the transaction was initiated by the customer or the merchant, and whether
3-D Secure
 authentication is used in the transaction.

Pay as You Go First Transaction

The first transaction that is initiated by the customer.
processingInformation.commerceIndicator
Set to
internet/oci/oci_attempted/oci_failure
.
processingInformation.authorizationOptions. initiator.type
Set to
customer
.
processingInformation.authorizationOptions. initiator.credentialStoredOnFile
Set to
true
.
The first transaction that is initiated by the merchant.
processingInformation.commerceIndicator
Set to
internet
.
processingInformation.authorizationOptions. initiator.type
Set to
merchant
.
processingInformation.authorizationOptions. initiator.credentialStoredOnFile
Set to
true
.

Pay as You Go Subsequent Transaction

Pay as You Go subsequent transactions must include these additional fields in the sales transaction.
Pay as You Go subsequent transactions that are initiated by the customer.
processingInformation.commerceIndicator
Set to
internet/oci/oci_attempted/oci_failure
.
processingInformation.authorizationOptions. initiator.type
Set to
customer
.
processingInformation.authorizationOptions. initiator.storedCredentialUsed
Set to
true
.
Pay as You Go subsequent transactions that are initiated by the merchant.
processingInformation.commerceIndicator
Set to
internet
.
processingInformation.authorizationOptions. initiator.type
Set to
merchant
.
processingInformation.authorizationOptions. initiator.storedCredentialUsed
Set to
true
.

Recurring First or Registration Transaction

First or registration transactions must include these additional fields in the sales transaction. There are two sets of fields that can be used depending upon whether
3-D Secure
 authentication occurs with the tranaction. Option 1 is the preferred set of fields to use.
First or registration transactions that are initiated by the customer: Option 1
processingInformation.commerceIndicator
Set to
internet/oci/oci_attempted/oci_failure
.
processingInformation.authorizationOptions. initiator.type
Set to
customer
.
processingInformation.authorizationOptions. initiator.credentialStoredOnFile
Set to
true
.
recurringPaymentInformation.type
Set to
1
.
First or registration transactions that are initiated by the customer: Option 2 (
3-D Secure
 authentication cannot be done)
processingInformation.commerceIndicator
Set to
recurring
.
processingInformation.authorizationOptions. initiator.type
Set to
customer
.
Initiated by the merchant
processingInformation.commerceIndicator
Set to
internet
.
processingInformation.authorizationOptions. initiator.type
Set to
merchant
.
processingInformation.authorizationOptions. initiator.credentialStoredOnFile
Set to
true
.
recurringPaymentInformation.type
Set to
1
.

Subsequent Recurring Transaction

Subsequent transactions must include these additional fields in the sales transaction. There are two sets of fields that can be used depending upon whether
3-D Secure
 authentication occurs with the tranaction. Option 1 is the preferred set of fields to use.
Subsequent recurring transactions that are initiated by the merchant: Option 1
processingInformation.commerceIndicator
Set to
internet
.
processingInformation.authorizationOptions. initiator.type
Set to
merchant
.
processingInformation.authorizationOptions. initiator.storedCredentialUsed
Set to
true
. (optional)
recurringPaymentInformation.type
Set to
2
.
Subsequent recurring transactions that are initiated by the merchant: Option 2
processingInformation.commerceIndicator
Set to
recurring
.
processingInformation.authorizationOptions. initiator.type
Set to
merchant
.

First or Registration Installment Transaction

First installment or registration transactions must include these additional fields in the sales transaction. There are two sets of fields that can be used depending upon whether
3-D Secure
 authentication occurs with the tranaction. Option 1 is the preferred set of fields to use.
The first or registration installment transaction that is initiated by the customer: Option 1
processingInformation.commerceIndicator
Set to
internet/oci/oci_attempted/oci_failure
.
processingInformation.authorizationOptions. initiator.type
Set to
customer
.
processingInformation.authorizationOptions. initiator.credentialStoredOnFile
Set to
true
.
installmentInformation.paymentType
Set to
1
.
Initiated by the customer: Option 2 (
3-D Secure
 authentication cannot be done)
processingInformation.commerceIndicator
Set to
install
.
processingInformation.authorizationOptions. initiator.type
Set to
customer
.
The first or registration installment transaction that is initiated by the merchant
processingInformation.commerceIndicator
Set to
internet
.
processingInformation.authorizationOptions. initiator.type
Set to
merchant
.
processingInformation.authorizationOptions.initiator.credentialStoredOnFile
Set to
true
.
installmentInformation.paymentType
Set to
1
.

Subsequent Installment Transaction

Subsequent installment transactions must include these additional fields in the sales transaction. There are two sets of fields that can be used depending upon whether
3-D Secure
 authentication occurs with the tranaction. Option 1 is the preferred set of fields to use.
Subsequent installment transactions are initiated by the merchant: Option 1
installmentInformation.paymentType
Set to
2
.
processingInformation.commerceIndicator
Set to
internet
.
processingInformation.authorizationOptions. initiator.type
Set to
merchant
.
processingInformation.authorizationOptions. initiator.storedCredentialUsed
Set to
true
. (optional)
Subsequent installment transactions are nitiated by the merchant: Option 2
processingInformation.commerceIndicator
Set to
install
.
processingInformation.authorizationOptions. initiator.type
Set to
merchant
.

Sale Bundled with Payer Authentication Enroll Service

When a customer is authenticated without a challenge, the transaction can be authorized either in the same request or in a separate authorization request. Whether authorization occurs in the same request or a separate request, the values from the check enrollment response must be passed to the authorization request to qualify for a liability shift. This section provides information on how to process a transaction combined with authentication of the cardholder that does not require additional authentication.
For more information about Payer Authentication, see the
Payer Authentication Developer Guide
.

Endpoint

Set the
ccAuthService_run
 field to
true
, and the
ccCaptureService_run
 field to
true
.
Send the request to
https://ics2ws.ic3.com/commerce/1.x/transactionProcessor
.

Sale Bundled with Payer Authentication Validate Service

When a customer is authenticated after a challenge, the transaction can be authorized in the same request or in a separate authorization request. Whether authorization is combined with validation or occurs in a separate request, the values from the validation response must be passed to the authorization request to qualify for a liability shift to the issuing bank. This section provides information on how to process that type of transaction.
For more details about Payer Authentication, see the
Payer Authentication Developer Guide
.

Endpoint

Set the
ccAuthService_run
 field to
true
, and the
ccCaptureService_run
 field to
true
.
Send the request to
https://ics2ws.ic3.com/commerce/1.x/transactionProcessor
.

Follow-On Credits

This section provides the information you need in order to process a
follow-on credit
, which is linked to a sale.
The expiration date is optional for card-not-present refund transactions.

Endpoint

Set the
ccCreditService_run
 field to
true
.
Send the request to
https://ics2ws.ic3.com/commerce/1.x/transactionProcessor
.

Required Fields for Processing a
Follow-On Credit

Use these required fields for processing a
follow-on credit
.
ccCreditService_captureRequestID
ccCreditService_run
Set the value to
true
.
merchantID
merchantReferenceCode
Set to
merchantReferenceCode
 value used in corresponding capture or sale request.
purchaseTotals_currency
purchaseTotals_grandTotalAmount

Simple Order Example: Processing a Follow-On Credit

Request
<requestMessage xmlns="urn:schemas-cybersource-com:transaction-data-1.86">
  <merchantID>merchantID</merchantID>
  <merchantReferenceCode>merchantRefCode</merchantReferenceCode>
  <purchaseTotals>
    <currency>USD</currency>
    <grandTotalAmount>1.01</grandTotalAmount>
  </purchaseTotals>
  <ccCreditService run="true">
    <captureRequestID>captureRequestID</captureRequestID>
  </ccCreditService>
</requestMessage>
Response to a Successful Request
<c:replyMessage xmlns:c="urn:schemas-cybersource-com:transaction-data-1.86">
  <c:merchantReferenceCode>Postman-1666641056</c:merchantReferenceCode>
  <c:requestID>6666410568976150003010</c:requestID>
  <c:decision>ACCEPT</c:decision>
  <c:reasonCode>100</c:reasonCode>
  <c:purchaseTotals>
    <c:currency>USD</c:currency>
  </c:purchaseTotals>
  <c:ccCreditReply>
    <c:reasonCode>100</c:reasonCode>
    <c:requestDateTime>2022-10-24T19:50:57Z</c:requestDateTime>
    <c:amount>1.01</c:amount>
    <c:reconciliationID>6691571329CM5P99</c:reconciliationID>
    <c:authorizationCode>831111</c:authorizationCode>
    <c:processorResponse>00</c:processorResponse>
    <c:paymentNetworkTransactionID>222222222222222</c:paymentNetwork>
  </c:ccCreditReply>
</c:replyMessage>

Stand-Alone
Stand-Alone Credits

This section shows you how to process a
stand-alone
credit, which is not linked to a capture or sale. There is no time limit for requesting a
stand-alone
credit.
You can process a stand-alone credit, which is not linked to a sale transaction. When you request a void for the credit and the credit is voided, if your account is enabled for credit authorizations, the credit authorization is also reversed.
The expiration date is optional for card-not-present stand-alone credit transactions.

Endpoint

Set the
ccCreditService_run
 field to
true
.
Send the request to
https://ics2ws.ic3.com/commerce/1.x/transactionProcessor
.

Required Fields for Processing a
Stand-Alone
Credit

Use these required fields for processing a
stand-alone
credit.
billTo_city
billTo_country
billTo_email
billTo_firstName
billTo_lastName
billTo_postalCode
billTo_state
billTo_street1
card_accountNumber
card_expirationMonth
card_expirationYear
ccCreditService
Set the value to
true
. For example
ccCreditService run="true"
.
merchantID
merchantReferenceCode
Set to
merchantReferenceCode
 value used in corresponding capture request.
purchaseTotals_currency
purchaseTotals_grandTotalAmount

Simple Order Example: Processing a Stand-Alone Credit

Request
<requestMessage>
    <billTo>
        <firstName>John</firstName>
        <lastName>Doe</lastName>
        <street1>1295 Charleston Road</street1>
        <city>Mountain View</city>
        <state>CA</state>
        <postalCode>94043</postalCode>
        <country>US</country>
        <email></email>
    </billTo>
    <card>
        <accountNumber>4111111111111111</accountNumber>
        <expirationMonth>12</expirationMonth>
        <expirationYear>2023</expirationYear>
    </card>
    <merchantID>lrsebctest</merchantID>
    <merchantReferenceCode>Postman-1666381004</merchantReferenceCode>
    <purchaseTotals>
        <currency>USD</currency>
        <grandTotalAmount>1.01</grandTotalAmount>
    </purchaseTotals>
    <ccCreditService run="true"/>
</requestMessage>
Response to a Successful Request
<c:replyMessge>
    <c:merchantReferenceCode>Postman-1666374834</c:merchantReferenceCode>
    <c:requestID>6663748348516429203007</c:requestID>
    <c:decision>ACCEPT</c:decision>
    <c:reasonCode>100</c:reasonCode>
    <c:purchaseTotals>
        <c:currency>USD</c:currency>
    </c:purchaseTotals>
    <c:ccAuthReply>
        <c:reasonCode>100</c:reasonCode>
        <c:amount>1.01</c:amount>
        <c:authorizationCode>888888</c:authorizationCode>
        <c:avsCode>X</c:avsCode>
        <c:avsCodeRaw>I1</c:avsCodeRaw>
        <c:authorizedDateTime>2022-10-21T17:53:54Z</c:authorizedDateTime>
        <c:processorResponse>100</c:processorResponse>
        <c:reconciliationID>66737280B9CGUCCP</c:reconciliationID>
        <c:paymentNetworkTransactionID>123456789619999</c:paymentNetworkTransactionID>
    </c:ccAuthReply>
    <c:card>
        <c:cardType>001</c:cardType>
    </c:card>
</c:replyMessge>

Void for a Sale
or Stand-Alone Credit Transaction

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

Void a Sale Transaction

Endpoint

Void a Stand-Alone Credit Transaction

Endpoint

Required Fields for Voiding a Sale

merchantID
merchantReferenceCode
voidService_voidRequestID
Set this field to the request ID that was included in the sale response message.
voidService_run
Set the value to
true
.

Stand-Alone Credit
Timeout Void for a Sale or a Stand-Alone Credit Transaction

When you do not receive a response message after requesting a capture, sale,
follow-on credit
, or
stand-alone credit
, this feature enables you to void the transaction that you requested.
Include the
merchantTransactionIdentifier
 field in the original request for a capture, sale,
follow-on credit
, or
stand-alone credit
. The value of the merchant transaction ID must be unique for 180 days.
When the original transaction fails, the response message for the reversal request includes these fields:
  • originalTransaction_amount
  • originalTransaction_reasonCode

Endpoint

Required Fields for a Time-Out Void for a Capture, Sale,
Follow-On Credit
, or
Stand-Alone Credit

merchantID
merchantReferenceCode
merchantTransactionIdentifier
Identifier that links the reversal request to the original request.
voidService_voidRequestID
Set this field to the request ID that was included in the authorization response message.
voidService_run
Set the value to
true
.

Simple Order Example: Time-Out Void for a Capture, Sale, Follow-On Credit, or Stand-Alone Credit

Request 
merchantID=Napa Valley Vacations
merchantReferenceCode=482046C3A7E94F5
voidService_run
voidService_voidRequestID=6522033834410167772169
Response to a Successful Request
requestID=0305782650000167905080
decision=ACCEPT
reasonCode=100
merchantReferenceCode=482046C3A7E94F5
purchaseTotals_currency=USD
ccAuthReply_reconciliationID=ABCDE12345FGHIJ67890
ccAuthReply_cardCategory=F^
ccAuthReply_cardGroup=0
ccAuthReply_reasonCode=100
ccAuthReply_amount=49.95
ccAuthReply_accountBalance=50.05
ccAuthReply_authorizationCode=123456
ccAuthReply_avsCode=Y
ccAuthReply_avsCodeRaw=YYY
ccAuthReply_processorResponse=A
ccAuthReply_paymentNetworkTransactionID=3312345