SCA Functional Specification

Requests to SCA

All request messages should have a document element of TRANSACTION. Each field name should be
represented by a child element’s tag name and the text content should represent that field’s value. The
following elements are required for all requests, except for SECURITY functions.

Example:

<TRANSACTION>                                   // Start of TRANSACTION
    <FUNCTION_TYPE>SESSION</FUNCTION_TYPE>      // FUNCTION_TYPE = SESSION
    <COMMAND>START</COMMAND>                    // COMMAND = START
    <COUNTER>1</COUNTER>                        // COUNTER = 1
    <MAC> … </MAC>                              // MAC = …
    <MAC_LABEL>REG2</MAC_LABEL>                 // MAC_LABEL = REG2
</TRANSACTION>                                  // End of TRANSACTION

Responses from Point

All responses will have a document element of RESPONSE. With the exception of reports, each RESPONSE element has at least the following fields.

Each field name should be represented by a child element’s tag name and the text content should
represent that field’s value.

Example:

<RESPONSE>                                                      // Start of RESPONSE
    <TERMINATION_STATUS>SUCCESS</TERMINATION_STATUS>            // TERMINATION_STATUS=SUCCESS
    <RESULT_CODE>-1</RESULT_CODE>                               // RESULT_CODE=-1
    <RESULT>OK</RESULT>                                         // RESULT=OK
    <RESPONSE_TEXT>SESSION started</RESPONSE_TEXT>              // RESPONSE_TEXT=SESSION started
<RESPONSE>                                                      // End of RESPONSE

All PAYMENT non-follow-on transaction responses (e.g., AUTHORIZATION or CAPTURE) will include both a
TROUTD and CTROUTD in the RESPONSE element unless transaction was processed offline or ERROR.

PAYMENT transaction responses may conditionally contain any of the following in the RESPONSE element.

Follow-on Transactions

To allow an integrated application to process follow on transactions effectively, it is recommended that the
application:

1. Store the TROUTD and CTROUTD values

2. Store the status of the transaction:

   1. Whether it has been voided
   2. Whether it has been completed
   3. Whether the gratuity has been added
   4. Whether it has been settled (and is not eligible for further follow on transactions)

If the application will store this information, lists or menu options should be provided by the application
that allow merchants to perform follow on transactions easily.
Alternatively, with Classic implementations, the merchant can use the Store Portal (virtual terminal) to
process follow on transactions. The Store Portal allows all follow on transactions to be processed, such
as Voids, Credits, Completions, and Tips.

Transaction Results

The successful response varies depending on card type, but the failure response will always be either
ERROR or DECLINED.

• CAPTURED: This response indicates the transaction is eligible for settlement.
• APPROVED: This response indicates the cardholder’s available credit has reduced by the amount of the AUTHORIZE transaction, but the transaction will not be eligible for settlement until it is followed by a CAPTURE transaction.
• ERROR: This response typically indicates a communication problem, but it can appear at other times.
• DECLINED: This response indicates that transaction was sent to the payment processing company, but they declined it.
• DECLINED DUPLICATE TRANSACTION: This response indicates the transaction was declined by the Point platform as a duplicate transaction. The merchant has the option to resubmit the transaction and force the Point platform to send the duplicate transaction to the payment processor.

Refer to Result/Error Codes for more information about the required RESPONSE elements.

Two Way Card Token

PAYMENT transaction responses may conditionally contain a two way token in the RESPONSE element (in
a non-token transaction). PAYMENT transaction requests may conditionally contain a token in the
REQUEST element (when token is known).