Use create_special_tender to start gift card transactions

Prototype the callback

Prototype the create_new_tender_CB and pass this as a parameter of the function pointer to the create_special_tender call. 

Code example

The callback function declaration is:

void create_new_tender_CB(create_tender_response *response, void *echo_struct){
	app_context_t *sPOS = (app_context_t *)echo_struct;
if (response->tender_reference) {
		safe_strdup(&sPOS->tender_reference, response->tender_reference);
		sPOS->pending_callback = 0; //mark ok......
	} else {
		sPOS->pending_callback = -1;
}

Allocate request structure

Use create_special_tender_request to allocate memory for an special_tender_request structure. Populate the request by performing string duplication and filling heap allocated strings. If you want the data for later use, retain it, or it will be released automatically.

special_tender_request *request = create_special_tender_request();
    if (request) {
        request->reference = strdup("Simple transaction");
        request->merchant_account = strdup(sPOS->merchant_account);
        request->terminal_id = strdup(sPOS->terminal_id);

Entry modes

The gift card can be presented on three ways: 

  1. Swipe: The gift card is read through a magnetic stripe.
  2. MKE on PED: The card number is manually entered on the payment terminal (PED). The tender should specify that it expects keyed entry on the terminal, and a card mask should be provided.
  3. MKE on POS: Scan a barcode on the back of the card from the Cash register application (POS). In this scenario, the card number, card mask and expiry should be provided in special options.

You can specify entry modes by passing special tender options. See Gift Card Matrix

Add and remove special options

Special options are dictionary key value pairs. This information is passed directly to the PED, which interprets it.

Use special_tender_add_option to set  special options, passing the request along with key value pairs. Use special_tender_rm_option to remove the set options.

special_tender_add_option(request, "cardNumber", "60362821657200117610");
        special_tender_add_option(request, "cardNumber.expiryMonth", "12");
        special_tender_add_option(request, "cardNumber.expiryYear", "2049");

Populate the create_special_tender_request

Populate the request using string duplication.

special_tender_request *request = create_special_tender_request();
	if (request) {
		request->reference = strdup("Simple transaction");
		request->merchant_account = strdup(sPOS->merchant_account);
		request->terminal_id = strdup(sPOS->terminal_id);
		request->amount_currency = strdup(sPOS->currency);
		request->amount_value = sPOS->amount;
		request->transaction_type = strdup("balanceInquiry");
		request->payment_method_type = strdup("goldsmithscard");
		special_tender_add_option(request, "cardNumber", "60362821657200117610");
		special_tender_add_option(request, "cardNumber.expiryMonth", "12");
		special_tender_add_option(request, "cardNumber.expiryYear", "2049");
		/* additional data is accessible like below
			request->additional_data_obj
		*/
		result = create_special_tender(request, create_new_tender_CB, sPOS);
	}
	

Call the create_special_tender Function

Call the create_special_tender function to Initiate the sale transaction, which triggers any relevant callbacks, and pass in the request that was previously allocated.

The POS waits for the final state and the  status_tender_final  callback to report the final result of the transaction, even if a cancel request has been issued. The reason for this is that the transaction might already be in a state in which a cancel is not possible.

The sale transaction includes the merchant account information, as this is used to register PEDs for multiple merchant accounts, and transactions can be performed on more than one of these merchant accounts.

result = create_special_tender(request, create_new_tender_CB, sPOS);

Parameters

Value Description
request Pointer to the special_tender_request struct, this struct contains all the input parameters for this call.
create_new_tender_CB Pointer to the callback function in the POS that will be called with the results of the create special tender call
echo_struct Pointer to a POS defined struct. Returned in the callback. It can be used to share a POS data struct between the call to the library and the callback from the library.

Code example

The declaration of the call to start a transaction is as follows:

result = create_special_tender(request, create_new_tender_CB, sPOS);

Handle the callback

Handle the create_new_tender_CB to check if the transaction was accepted by the terminal by checking if tender_reference was populated by the library. 

 if (response->tender_reference) {
  safe_strdup(&sPOS->tender_reference, response->tender_reference);
  sPOS->pending_callback = 0; //mark ok......
 } else {
  sPOS->pending_callback = -1;
 }

Check the result by getting information from the create_tender_response.

The POS needs to wait for the create_new_tender_CB to happen, before it can continue with other functions.  After the create_new_tender_CB is returned, the system returns a number of other callbacks. Finally, the system returns the final callback that contains the final transaction result. Another transaction can only be started when the final transaction result is received.

Parameters

Data element Description
create_tender_response A unique reference for the transaction that is generated by the PED device. This reference is used for subsequent actions on the transaction. For a list of parameters, see create_tender_response.
echo_struct Pointer to a user-defined struct. Returned in the callback. It can be used to share a POS data struct between the call to the library and the callback from the library in response to the call.

The create_new_tender_CB is a callback to the creation of a tender, but does not represent the status or result of the transaction. The result is returned in tender_finished_CB.