Overview

The GPN DATA 64x Token API is the method by which GPN DATA conducts secure, PCI DSS 3.2 compliant sensitive payment instrument data and customer personal data persistence,allowing Merchants to perform transactions involving usage of aforementioned data, taking of burden of being PCI DSS compliant in terms of storage and processing.

The target audience of this document is the Programmer or IT professional who will be integrating the GPN DATA 64x Token API into the Merchant’s hosted e-commerce solution.

GPN DATA strictly adheres to the standards set forth by PCI DSS (Payment Card Industry Data Security Standard) and by exposing 64x Token API takes off responsibility of storing CHD (Card Holder Data) from its non-PCI DSS compliant Merchants. Nevertheless, for non-PCI DSS compliant parties, it remains strictly forbidden to store CHD in any other mean except instrument tokens provided by GPN DATA system. To obtain the latest information regarding PCI-DSS please consult:

https://www.pcisecuritystandards.org/security_standards/documents.php

All information contained in this document is the intellectual property of GPN DATA Europe Ltd. and is protected by International Copyrights.

All references in this document to “gateway” or Gateway” directly refer to GPN DATA Europe unless otherwise specified.

All information in this document is subject to Non-Disclosure Agreements signed by the principal officer of the Merchant.

Terminology

Instrument

An entity that provides method of payment. i.e. credit card, but instruments may vary by payment type (cards, accounts etc.) and funding type (credit, debit etc.).

Instrument consist of data that are used to differentiate one from another. This data is stored in GPN DATA database in secure way, involving encrypting and hashing methodologies.

Customer entity

Entity of customer profile (aggregation of personal data) that Merchant has on his system. Customer entities are identified by Merchant’s account id .

Account id

This is unique number of customer entity that is held on Merchant’s system.

Instrument token entities are associated with customer entity of given account id.

Instrument token

Retrieved by token unique id. A point of reference to payment instrument.   



Test Server: https://txtest.txpmnts.com/api/transaction/
PROD. Server: https://txpmnts.com/api/transaction/

cURL Request Sample
   
        $ch = curl_init();
         
         
        //Set up curl parameters
		curl_setopt($ch, CURLOPT_URL, 'https://txtest.txpmnts.com/api/transaction/');        // set remote address
        curl_setopt($ch, CURLOPT_POSTFIELDS, $requestMessage);
        curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);    // Make CURL pass the response as a curl_exec return value instead of outputting to STDOUT
        curl_setopt($ch, CURLOPT_POST, 1);                // Activate the POST method
        curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0);
        curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 0);
        curl_setopt($ch, CURLOPT_VERBOSE, 0);
        // curl_setopt($ch, CURLOPT_HEADER, 0);
        curl_setopt($ch, CURLOPT_HTTPHEADER, [
            'Content-type: text/xml',
            'Accept: text/xml'
        ]);
         
        //execute the connection
        $result = curl_exec($ch);
         
        echo "
Result Code:
".$result.']]>
';
         
        $debugoutput = curl_getinfo($ch);
         
        $curl_error_message = curl_error($ch); // must retrieve an error message (if any) before closing the curl object
         
        echo "
Curl Error message:".$curl_error_message;
         
        curl_close($ch);
 
         
        //Trim headers
        $pos = strstr($result, "\n");
        echo '
Result'.$pos;

GPN DATA MERCHANT API

API Commands are send from merchant’s system to the Gateway with HTTP protocol. Request need to be sent to URL provided by GPN Data. Data is transmitted as POST parameter strrequest , which contain XML string with the API Command required details.

API 640: Creating a customer entity and instrument tokens

Creation of customer entity alone

Merchant can store information about his customers in GPN Data storage. This functionality is primarily used for further instrument assignation to created customer accounts, but also might be used to remove burden of storing sensitive customer data on merchant’s side.

It can be done via API 640 request either by sending customer account’s personal information along with <accountid>. Account id is the only data that merchant needs to store after successful customer entity creation. Thanks to this, merchant is no longer obliged to send full customer data with transactions requiring it, <customer><accountid>{ account id }</accountid></customer> will be enough.

In case created customer entity’s full customer data is required by merchant (i.e. to be displayed on merchant hosted website), retrieval is possible via API 641 call, which is described in next chapter.

640 Request Data description:

Node Include in Checksum (in this order) Optional Data Type Description
apiUser YES (1) YES Character max 50. The API user assigned by the Gateway to the merchant. Can be obtained from the website inside your merchant account.
apiPassword YES (2) YES Character max 50. The API password assigned by Gateway to the merchant. Can be obtained from the website inside your merchant account.
apiCmd YES (3) YES 640 3 digit numeric transaction code must be 640
customer YES Xml Node Section containing Customer Information
customer->accountid YES (4) YES Character max 50. Customer’s account id in Merchant’s system.
customer->firstname OPT Character max 50. First name of the Customer. Required when creating customer entity.
customer->lastname OPT Character max 50. Last name of the Customer.
customer->birthday OPT Number 1-2 digits Day of birth of the Customer (1-31) Required when creating customer entity.
customer->birthmonth OPT Number 1-2 digits Month of birth of the customer (1-12) Required when creating customer entity.
customer->birthyear OPT Number 4 digits Customer’s year of birth (1900-2100). Required when creating customer entity.
customer->email OPT Character max 100. Email of the Customer. Required when creating customer entity.
customer->countryiso OPT Character exactly 3. 3 letter ISO country code of the Customer. Required when creating customer entity.
customer->stateregioniso OPT Character max 3. 1-3 character ISO 3166 state/region/province code of the Customer. Required when creating customer entity.
customer->zippostal OPT Character max 15. Customer’s Zipcode or postal code. Required when creating customer entity.
customer->city OPT Character max 50. Customer’s City Required when creating customer entity.
creditcard OPT Xml Node Credit card instrument information. Required for credit card instrument creation.
creditcard->ccnumber YES (5) if present OPT Character max 16. Full credit card number without dashes or separators. Only numbers.
creditcard->cccvv YES (6) if present OPT Character max 4. Verification Code of the Credit Card
creditcard->expmonth OPT Numeric 1-2 Expiration month of the credit card.
creditcard->expyear OPT Numeric 4 Expiration year of the credit card.
creditcard->nameoncard YES (7) if present OPT Character max 50. Full name as it appears on card.

The structure of API 640 contract, creating customer entity alone, presents as follows:

  <?xmlversion="1.0" encoding="utf-8" ?>
	<transaction>
	<apiUser>(…)</apiUser>
	<apiPassword>(…)</apiPassword>
	<apiCmd>640</apiCmd>
		<customer> 
			<firstname>Devoted</firstname>
			<lastname>Customer</lastname>
			<accountid>000000000001</accountid>
			<ipaddress>0.0.0.0</ipaddress>
			<email>[email protected]</email>
			<city>Miami</city>
			<countryiso>USA</countryiso>
			<birthday>10</birthday>
			<birthmonth>10</birthmonth>
			<birthyear>1990</birthyear>
			<stateregioniso>FL</stateregioniso>
			<zippostal>333211</zippostal>
			<address1>123 Devoted Ave</address1>
			<phone1phone>0000000001</phone1phone>
			</address2>
		</customer>
		<checksum>(…)</checksum>
	</transaction>

The response of successful request:


	<?xmlversion="1.0" encoding="utf-8" ?>
	<transaction>
	<result>SUCCESS</result>
	<errorcode>000</errorcode>
		<customer> 
			<firstname>Devoted</firstname>
			<lastname>Customer</lastname>
			<accountid>000000000001</accountid>
			<ipaddress>0.0.0.0</ipaddress>
			<email>[email protected]</email>
			<city>Miami</city>
			<countryiso>USA</countryiso>
			<birthday>10</birthday>
			<birthmonth>10</birthmonth>
			<birthyear>1990</birthyear>
			<stateregioniso>FL</stateregioniso>
			<zippostal>333211</zippostal>
			<address1>123 Devoted Ave</address1>
			<phone1phone>0000000001</phone1phone>
			</address2>
		</customer>
	</transaction>

Creation of customer entity simultaneously with customer instrument token

Having a situation when merchant is willing to register a customer entity along with instrument token at once, it is possible to do it with just one API 640 request.

Note: To perform simultaneous customer entity and instrument token creation, both customer entity and instrument must NOT be created before.

The structure of API 640 contract, creating customer entity, simultaneously with instrument token, presents as follows: 

  <?xmlversion="1.0" encoding="utf-8" ?>
	<transaction>
	<apiUser>(…)</apiUser>
	<apiPassword>(…)</apiPassword>
	<apiCmd>640</apiCmd>
		<customer> 
			<firstname>Devoted</firstname>
			<lastname>Customer</lastname>
			<accountid>000000000001</accountid>
			<ipaddress>0.0.0.0</ipaddress>
			<email>[email protected]</email>
			<city>Miami</city>
			<countryiso>USA</countryiso>
			<birthday>10</birthday>
			<birthmonth>10</birthmonth>
			<birthyear>1990</birthyear>
			<stateregioniso>FL</stateregioniso>
			<zippostal>333211</zippostal>
			<address1>123 Devoted Ave</address1>
			<phone1phone>0000000001</phone1phone>
			</address2>
		</customer>
		<creditcard> 
			<ccnumber>4242424242424242</ccnumber>
			<cccvv>224</cccvv>
			<expmonth>11</expmonth>
			<expyear>2020</expyear>
			<nameoncard>Evan Moore</nameoncard>
		</creditcard>
		<checksum>(…)</checksum>
	</transaction>

The response of successful request:


	<?xmlversion="1.0" encoding="utf-8" ?>
	<transaction>
	<result>SUCCESS</result>
	<errorcode>000</errorcode>
		<token> 
			<object>token</object>
			<title>credit card</title>
			<token>76DD69A3-71F8-037B-A2BB-FE25835C383B</token>
			<bin>424242</bin>
			<last4>4242</last4>
			<expMonth>10</expMonth>
			<expYear>2020</expYear>
			<nameOnCard>Evan Moore</nameOnCard>
			<cardType>Visa</cardType>
			<expires>0</expires>
			<oneTime>0</oneTime>
			<used>0</used>
			<deleted>0</deleted>
			<accountId>0000000001</accountId>
			<whitelisted>1</whitelisted>
			<billing>.....</billing>
		</token>
		<customer> 
			<object>merchant account</object>
			<accountid>000000000001</accountid>
			<firstname>Devoted</firstname>
			<lastname>Customer</lastname>
			<email>[email protected]</email>
			<city>Miami</city>
			<countryiso>USA</countryiso>
			<birthday>10</birthday>
			<birthmonth>10</birthmonth>
			<birthyear>1990</birthyear>
			<stateregioniso>FL</stateregioniso>
			<zippostal>333211</zippostal>
			<address1>123 Devoted Ave</address1>
			</address2>
			<phone1phone>0000000001</phone1phone>
			</phone2phone>
			<ipaddress>0.0.0.0</ipaddress>
		</customer>
	</transaction>

Creation of customer entity simultaneously with customer instrument token

Once the customer entity exists in GPN DATA System, it is not allowed to create another customer account representation. On the other hand, Merchant’s webpage/system can employ API 640 call to add instrument tokens and API 643 to delete them. API 643 is described further in this guide.

Note: To perform instrument token creation, for particular customer entity, instrument must NOT be created before and customer entity must be already created. Only <accountid> of customer entity is to be provided in <customer> node.

The structure of API 640 contract, creating instrument token , for existing customer entity, presents as follows: 

  <?xmlversion="1.0" encoding="utf-8" ?>
	<transaction>
	<apiUser>(…)</apiUser>
	<apiPassword>(…)</apiPassword>
	<apiCmd>640</apiCmd>
		<customer> 
			<accountid>000000000001</accountid>
		</customer>
		<creditcard> 
			<ccnumber>4242424242424242</ccnumber>
			<cccvv>224</cccvv>
			<expmonth>11</expmonth>
			<expyear>2020</expyear>
			<nameoncard>Evan Moore</nameoncard>
		</creditcard>
		<checksum>(…)</checksum>
	</transaction>

The response of successful request:


	<?xmlversion="1.0" encoding="utf-8" ?>
	<transaction>
	<result>SUCCESS</result>
	<errorcode>000</errorcode>
		<token> 
			<object>token</object>
			<title>credit card</title>
			<token>36B1CC96-D92D-D18E-521C-D9886087A851</token>
			<bin>434342</bin>
			<last4>4343</last4>
			<expMonth>10</expMonth>
			<expYear>2018</expYear>
			<nameOnCard>Devoted Customer</nameOnCard>
			<cardType>Visa</cardType>
			<expires>0</expires>
			<oneTime>0</oneTime>
			<used>0</used>
			<deleted>0</deleted>
			<accountId>0000000001</accountId>
			<whitelisted>0</whitelisted>
			<billing>....</billing>
		</token>
		<customer> 
			<object>merchant account</object>
			<accountid>000000000001</accountid>
			<firstname>Devoted</firstname>
			<lastname>Customer</lastname>
			<email>[email protected]</email>
			<city>Miami</city>
			<countryiso>USA</countryiso>
			<birthday>10</birthday>
			<birthmonth>10</birthmonth>
			<birthyear>1990</birthyear>
			<stateregioniso>FL</stateregioniso>
			<zippostal>333211</zippostal>
			<address1>123 Devoted Ave</address1>
			</address2>
			<phone1phone>0000000001</phone1phone>
			</phone2phone>
			<ipaddress>0.0.0.0</ipaddress>
		</customer>
	</transaction>

API 641: Retrieving customer entity and token information

Retrieval by customer’s account id

With single API 641 call, provided <accountid>, all valuable customer information, including instrument tokens’ information from GPN DATA System can be retrieved.

641 Request Data description:

Node Include in Checksum (in this order) Optional Data Type Description
apiUser YES (1) YES Character max 50. The API user assigned by the Gateway to the merchant. Can be obtained from the website inside your merchant account.
apiPassword YES (2) YES Character max 50. The API password assigned by Gateway to the merchant. Can be obtained from the website inside your merchant account.
apiCmd YES (3) YES 640 3 digit numeric transaction code must be 640
customer YES Xml Node Section containing Customer Information
customer->accountid YES (4) if present OPT Character max 50. Customer’s account id in Merchant’s system. Required for retrieval by account id.
token OPT Xml Node Instrument token information. Required when retrieving by instrument token unique id.
token YES (4) if present OPT Character UUID v4 max 36. Unique id of instrument token. Required for retrieval by instrument token unique id

Request presents as follows: 
  <?xmlversion="1.0" encoding="utf-8" ?>
	<transaction>
	<apiUser>(…)</apiUser>
	<apiPassword>(…)</apiPassword>
	<apiCmd>641</apiCmd>
		<customer> 
			<accountid>000000000001</accountid>
		</customer>
	<checksum>(…)</checksum>
	</transaction>

The response of successful request:


	<?xmlversion="1.0" encoding="utf-8" ?>
	<transaction>
	<result>SUCCESS</result>
	<errorcode>000</errorcode>
		<customer> 
			<object>merchant account</object>
			<accountid>000000000001</accountid>
			<firstname>Devoted</firstname>
			<lastname>Customer</lastname>
			<email>[email protected]</email>
			<city>Miami</city>
			<countryiso>USA</countryiso>
			<birthday>10</birthday>
			<birthmonth>10</birthmonth>
			<birthyear>1990</birthyear>
			<stateregioniso>FL</stateregioniso>
			<zippostal>333211</zippostal>
			<address1>123 Devoted Ave</address1>
			</address2>
			<phone1phone>0000000001</phone1phone>
			</phone2phone>
			<ipaddress>0.0.0.0</ipaddress>
		</customer>
		<token> 
			<object>token</object>
			<title>credit card</title>
			<token>36B1CC96-D92D-D18E-521C-D9886087A851</token>
			<bin>434342</bin>
			<last4>4343</last4>
			<expMonth>10</expMonth>
			<expYear>2018</expYear>
			<nameOnCard>Devoted Customer</nameOnCard>
			<cardType>Visa</cardType>
			<expires>0</expires>
			<oneTime>0</oneTime>
			<used>0</used>
			<deleted>0</deleted>
			<accountId>0000000001</accountId>
			<whitelisted>0</whitelisted>
			<billing>....</billing>
		</token>
	</transaction>

API 641: Retrieving customer entity and token information

Retrieval by token instrument unique id

When information about customer entity with all associated tokens is too much, it is possible to retrieve just single instrument token information, passing its unique id in API 641 contract

Request presents as follows: 
  <?xmlversion="1.0" encoding="utf-8" ?>
	<transaction>
	<apiUser>(…)</apiUser>
	<apiPassword>(…)</apiPassword>
	<apiCmd>641</apiCmd>
		<token> 
			<token>36B1CC96-D92D-D18E-521C-D9886087A851</accountid>
		</token>
	<checksum>(…)</checksum>
	</transaction>

The response of successful request:


	<?xmlversion="1.0" encoding="utf-8" ?>
	<transaction>
	<result>SUCCESS</result>
	<errorcode>000</errorcode>
		<token> 
			<object>token</object>
			<title>credit card</title>
			<token>36B1CC96-D92D-D18E-521C-D9886087A851</token>
			<bin>434342</bin>
			<last4>4343</last4>
			<expMonth>10</expMonth>
			<expYear>2018</expYear>
			<nameOnCard>Devoted Customer</nameOnCard>
			<cardType>Visa</cardType>
			<expires>0</expires>
			<oneTime>0</oneTime>
			<used>0</used>
			<deleted>0</deleted>
			<accountId>0000000001</accountId>
			<whitelisted>0</whitelisted>
			<billing>....</billing>
		</token>
	</transaction>

API 642: Updating a customer entity

Retrieval by customer’s account id

Given scenario of customer operating on own account’s view at Merchant website, it is possible to update personal information of customer, stored on GPN DATA System. In behalf of customer wishing to change such data, Merchant system may send API 642 request, containing Merchant Account ID and all other personal information that is a subject of change (<address1> and <phone1phone> fields in this example):

Note: API 642 contract requires all node to be sent. That is why whole dataset needs to be passed regardless they are a subject of change or not. On above example, despite only and data differ from persisted customer data, all fields were sent.

Note: Be aware that changing customer entity personal data may cause customer matching rules breach! It is advised to contact GPN Data Technical Support to receive information about what values can be altered for your Merchant Profile.

The response of successful API 642 call looks exactly the same as API 641 call, listing all customer entity data (only already altered by request).

Note: Instrument tokens are meant to be unalterable. When instrument i.e. becomes expired, do not attempt to change expiry date of i.e. new credit card obtained from issuer with the same PAN but another expiry date. Delete instrument token when expired using API 643 call and create new one using API 640. API 643 is described in next chapter.

642 Request Data description:

Node Include in Checksum (in this order) Optional Data Type Description
apiUser YES (1) YES Character max 50. The API user assigned by the Gateway to the merchant. Can be obtained from the website inside your merchant account.
apiPassword YES (2) YES Character max 50. The API password assigned by Gateway to the merchant. Can be obtained from the website inside your merchant account.
apiCmd YES (3) YES 640 3 digit numeric transaction code must be 642
customer YES Xml Node Section containing Customer Information
customer->accountid YES (4) if present OPT Character max 50. Customer’s account id in Merchant’s system. Required for retrieval by account id.
customer->firstname OPT Character max 50. First name of the Customer. Required when creating customer entity.
customer->lastname OPT Character max 50. Last name of the Customer.
customer->birthday OPT Number 1-2 digits Day of birth of the Customer (1-31) Required when creating customer entity.
customer->birthmonth OPT Number 1-2 digits Month of birth of the customer (1-12) Required when creating customer entity.
customer->birthyear OPT Number 4 digits Customer’s year of birth (1900-2100). Required when creating customer entity.
customer->email OPT Character max 100. Email of the Customer. Required when creating customer entity.
customer->countryiso OPT Character exactly 3. 3 letter ISO country code of the Customer. Required when creating customer entity.
customer->stateregioniso OPT Character max 3. 1-3 character ISO 3166 state/region/province code of the Customer. Required when creating customer entity.
customer->zippostal OPT Character max 15. Customer’s Zipcode or postal code. Required when creating customer entity.
customer->city OPT Character max 50. Customer’s City Required when creating customer entity.
token OPT Xml Node Instrument token information. Required when retrieving by instrument token unique id.
token YES (4) if present OPT Character UUID v4 max 36. Unique id of instrument token. Required for retrieval by instrument token unique id

Request presents as follows: 
  <?xmlversion="1.0" encoding="utf-8" ?>
	<transaction>
	<apiUser>(…)</apiUser>
	<apiPassword>(…)</apiPassword>
	<apiCmd>642</apiCmd>
		<customer> 
			<firstname>Devoted</firstname>
			<lastname>Customer</lastname>
			<accountid>000000000001</accountid>
			<ipaddress>0.0.0.0</ipaddress>
			<email>[email protected]</email>
			<city>Miami</city>
			<countryiso>USA</countryiso>
			<birthday>10</birthday>
			<birthmonth>10</birthmonth>
			<birthyear>1990</birthyear>
			<stateregioniso>FL</stateregioniso>
			<zippostal>333211</zippostal>
			<address1>123 Devoted Ave</address1>
			</address2>
			<phone1phone>0000000001</phone1phone>
			</phone2phone>
			</customer>
	<checksum>(…)</checksum>
	</transaction>

API 643: Deleting an instrument token

If for some reason customer does not want to use a instrument token on Merchant’s website/system, there is a possibility to delete associated tokens. This can be achieved by sending API 643 request with instrument token unique id.

Note: Deleted instrument token is still retrievable and provides information about payment instrument, although it’s not possible to commit any transaction using it anymore.

643 Request Data description:

Node Include in Checksum (in this order) Optional Data Type Description
apiUser YES (1) YES Character max 50. The API user assigned by the Gateway to the merchant. Can be obtained from the website inside your merchant account.
apiPassword YES (2) YES Character max 50. The API password assigned by Gateway to the merchant. Can be obtained from the website inside your merchant account.
apiCmd YES (3) YES 643 3 digit numeric transaction code must be 642
token YES Xml Node Instrument token information.
token YES (4) if present OPT Character UUID v4 max 36. Unique id of instrument token.

Request presents as follows: 
  <?xmlversion="1.0" encoding="utf-8" ?>
	<transaction>
	<apiUser>(…)</apiUser>
	<apiPassword>(…)</apiPassword>
	<apiCmd>643</apiCmd>
		<token> 
			<token>A7BDE635-8C3E-18B4-469A-D005FCAD2D29</token>
		</token>
	<checksum>(…)</checksum>
	</transaction>
And the successful response, <deleted>1</deleted> value is present: 
  <?xmlversion="1.0" encoding="utf-8" ?>
	<transaction>
	<apiUser>(…)</apiUser>
	<apiPassword>(…)</apiPassword>
	<apiCmd>643</apiCmd>
		<token> 
			<object>token</object>
			<title>credit card</title>
			<token>36B1CC96-D92D-D18E-521C-D9886087A851</token>
			<bin>434342</bin>
			<last4>4343</last4>
			<expMonth>10</expMonth>
			<expYear>2018</expYear>
			<nameOnCard>Devoted Customer</nameOnCard>
			<cardType>Visa</cardType>
			<expires>0</expires>
			<oneTime>0</oneTime>
			<used>0</used>
			<deleted>1</deleted>
			<accountId>0000000001</accountId>
			<whitelisted>0</whitelisted>
			<billing>....</billing>
		</token>
	<checksum>(…)</checksum>
	</transaction>

Checksum Calculation

Checksum validation is a simple method to ensure the integrity of transferred data. Basically, we generate a hash out of the given parameters and your private API key. If you send us a request with transaction data and the generated checksum, we can easily validate the data. To make the checksum computation as easy as possible we provide this endpoint for you.

For transactions that are started client-side, it is required to first create a checksum on your server and then provide that checksum when starting the transaction in the transaction request. The checksum needs to contain all data required to subsequently create the actual transaction.

To assure the integrity of the information being sent, we use a checksum calculated using various parameters in a concatenated string and a sha1() function. The parameters used are the following and MUST be used in the order given:

  • 640 Checksum Calculation using SHA1:
    • API USER
    • API PASSWORD
    • CMD : 640
    • CC NUMBER
    • CC CVV
    • NAME ON THE CARD
    • ACCOUNT ID
    • API KEY
  • 641 Checksum Calculation using SHA1:
    • API USER
    • API PASSWORD
    • CMD : 641
    • TOKEN
    • ACCOUNT ID
    • API KEY
  • 642 Checksum Calculation using SHA1:
    • API USER
    • API PASSWORD
    • CMD : 642
    • ACCOUNT ID
    • API KEY
  • 643 Checksum Calculation using SHA1:
    • API USER
    • API PASSWORD
    • CMD : 643
    • TOKEN
    • API KEY

    • Checksum Calculation in PHP

     

$apiKey = '177987E1-43DC-934F-7C7C-227A22B5E2AC'; // <-- your apiKey
	$apiUser = '2486mesut'; // <-- your apiUser
	$apiPassword = 'b17d869a9ebd'; // <-- your apiPassword
	$firstname = 'Jony'; 
	$lastname = 'Caption';
	$email = '[email protected]'; 
	$countryiso = 'USA';
	$stateregioniso = 'FL';
	$zippostal = '98111';
	$city = 'Miami';
	$address1 = '123 ave test';
	 $cmd = '640';
	$accountid = '12322211222'; // Unique ID for each customer
	$ipaddress = '192.168.0.0';	 
	$cccvv = '251';
	$ccnumber = "4716897059110821"
	$expmonth = '10';
	$expyear = '2018';
	$nameoncard = 'Jony Caption';
	// Checksum calculation - see the Data Table for the API Command being used to verify the fields used and the field order
	$checksum = sha1($apiUser.$apiPassword.$cmd.$ccnumber.$cccvv.$nameoncard.$accountid.$apiKey);
	 
//create XML of data to be posted
	$requestMessage = '<?xml version="1.0" encoding="utf-8" ?>
		<transaction>
				 <apiUser>'.$apiUser.'</apiUser>
				<apiPassword>.$apiPassword.'</apiPassword>
				 <apiCmd>'.$cmd.'</apiCmd>
				 <checksum>'.$checksum.'</checksum>
			<customer>
				<firstname>'.$firstname.'</firstname>
				<lastname>'.$lastname.'</lastname>
				<accountid>'.$accountid.'</accountid>
				<ipaddress>'.$ipaddress.'</ipaddress>
				<email>'.$email.'</email>
				<city>'.$city.'</city>
				<countryiso>'.$countryiso.'</countryiso>
				<stateregioniso>'.$stateregioniso.'</stateregioniso>
				<zippostal>'.$zippostal.'</zippostal>
				<<address1>'.$address1.'</address1>
			</customer>
			<creditcard>
				<ccnumber>'.$ccnumber.'</ccnumber>
				<cccvv>'.$cccvv.'</cccvv>
				<expmonth>'.$expmonth.'</expmonth>
				<expyear>'.$expyear.'</expyear>
				<nameoncard>'.$nameoncard.'</nameoncard>
			</creditcard>
		</transaction>
	';
 
        echo '
    Request Message :'.$requestMessage;
         
         
        $ch = curl_init();
         
         
        //Set up curl parameters
        curl_setopt($ch, CURLOPT_URL, 'https://txtest.txpmnts.com/api/transaction/');       // set remote address
        curl_setopt($ch, CURLOPT_POSTFIELDS, http_build_query(array('strrequest' =>$requestMessage)));
        curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);    // Make CURL pass the response as a curl_exec return value instead of outputting to STDOUT
        curl_setopt($ch, CURLOPT_POST, 1);              // Activate the POST method
        curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0);
        curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 0);
        curl_setopt($ch, CURLOPT_VERBOSE, 0);
        curl_setopt($ch, CURLOPT_HEADER, 0);
         
        //execute the connection
        $result = curl_exec($ch);
         
        echo "
    Result Code:
    ".$result.']]>
    ';
         
        $debugoutput = curl_getinfo($ch);
         
        $curl_error_message = curl_error($ch); // must retrieve an error message (if any) before closing the curl object
         
        echo "
    Curl Error message:".$curl_error_message;
         
        curl_close($ch);

    Token IFrame Integration

    You can get a token to make a secure transaction.
    To see Checkout in action, click the button below.

    <!DOCTYPE html>
    <html lang="en">
        <head>
            ...
        </head>
        <body>
            ...
            ...
            <script type="text/javascript" src="https://checkouttest.txpmnts.com/checkout.js"></script>
        </body>
    </html>

    Options

    Options can be passed via data attributes or JavaScript. For data attributes, append the option name to data-, as in data-locale="".

    If Server is yes means that we will send you back this option after get the token.
    Name Type Default Server Description
    locale string auto No -
    keyboard boolean true No Closes the modal when escape key is pressed.
    allow-change-language boolean true No -
    terms string null No -
    start-page string page-order-summary No -
    account-description string null No -
    account-logo-url string null No -
    account-key string null No -
    method string null Yes -
    orders string [ ] No -
    currency string USD Yes -
    decimal-digits integer 2 Yes -
    billing-enabled boolean true Yes -
    billing-firstname string null Yes -
    billing-lastname string null Yes -
    billing-email string null Yes -
    billing-phone string null Yes -
    billing-address-line1 string null Yes -
    billing-address-line2 string null Yes -
    billing-postal-code string null Yes -
    billing-city string null Yes -
    billing-state string null Yes -
    billing-country string null Yes -
    shipping-enabled boolean true Yes -
    shipping-firstname string null Yes -
    shipping-lastname string null Yes -
    shipping-email string null Yes -
    shipping-phone string null Yes -
    shipping-address-line1 string null Yes -
    shipping-address-line2 string null Yes -
    shipping-postal-code string null Yes -
    shipping-city string null Yes -
    shipping-state string null Yes -
    shipping-country string null Yes -
    same-billing-shipping boolean true Yes -

    Methods

    We also export the variable Gpn.checkout so you can build your payment button via javascript.

    Name Description
    .open(handler, onComplete) Show the iframe by passing the corresponding handler.
    .close() Hide the iframe.
    .setup(options) Setup the iframe and return the corresponding handler.
    .isShown() Return true if the iframe is shown.

    Token IFrame Request Sample:

     
<form action="https://checkouttest.txpmnts.com/documentation/charge-succeed" method="post">
<button
	class="btn btn-primary gpndata-button"
	data-locale="auto"
	data-keyboard="true"
	data-terms="https://gpndata.com/terms-and-conditons/"
	data-account="Account Store"
	data-account-description="The best store in poland."
	data-account-logo-url="https://checkouttest.txpmnts.com/bundles/doc/img/store-icon.png"
	data-account-key="959449ae2d54cdd739dd6c23ccf579a1c181926e"
	data-orders='[{"description": "TV", "price": 100045, "quantity": 2}, {"description": "Laptop", "price": 200000, "quantity": 1}, {"description": "Phone", "price": 20000, "quantity": 3}]'
	data-currency="USD"
	data-billing-enabled="true"
	data-billing-firstname="Jone"
	data-billing-lastname="Doe"
	data-billing-email="[email protected]"
	data-billing-phone="+48 123456789"
	data-billing-address-line1="Avenue 21"
	data-billing-address-line2=""
	data-billing-address-postal-code="12-345"
	data-billing-address-city="Oz City"
	data-billing-address-state="MZ"
	data-billing-address-country="PL"
	data-shipping-enabled="true"
	data-shipping-firstname="Jane"
	data-shipping-lastname="Doe"
	data-shipping-email="[email protected]"
	data-shipping-phone="+48 123456789"
	data-shipping-address-line1="Street 24"
	data-shipping-address-line2=""
	data-shipping-address-postal-code="54-321"
	data-shipping-address-city="Oz City"
	data-shipping-address-state="MZ"
	data-shipping-address-country="PL"
	data-same-billing-shipping="true"
>Pay with GPN DATA</button>
		</form>

    Token IFrame - JavaScript Request Sample:

    We also export the variable Gpn.checkout so you can build your payment button via javascript. 

    

// input.js
var handler = Gpn.checkout.setup({
    locale: 'auto',
    keyboard: true,
    terms: 'http://www.yourbusiness.com/terms-and-conditons/',
    account: 'Your Business',
    accountDescription: 'The best business in the world.',
    accountLogoUrl: 'http://www.yourbusiness.com/logo.png',
    accountKey: 'your-public-key',
    currency: 'USD',
    orders: [
        {description: 'TV', price: 2000, quantity: 1},
        {description: 'Phone', price: 1000, quantity: 3}
    ],
    billingEnabled: true,
    shippingEnabled: true,
});

var buttonElem = document.getElementById('btn-pay');

buttonElem.addEventListener('click', function () {
    Gpn.checkout.open(handler, function(data) {
        // data contains the token and all options marked as Yes on Server....
        var token = data.token;
        ...
    });
});

    Methods

    We also export the variable Gpn.checkout so you can build your payment button via javascript.

    Name Description
    .open(handler, onComplete) Show the iframe by passing the corresponding handler.
    .close() Hide the iframe.
    .setup(options) Setup the iframe and return the corresponding handler.
    .isShown() Return true if the iframe is shown.

    * options: Object with the options to setup the iframe. You can use all options described above but in camelcase.

    Events

    All events are fired on the button element that show or hide the iframe.

    Event type Description
    gpndata.payform.ready It is triggered when iframe is ready.
    gpndata.payform.opened It is triggered after iframe is shown.
    gpndata.payform.closed It is triggered after iframe is hidden.
    // You should not trigger the iframe before this happen.
    window.addEventListener(Gpn.constant.EVENT_READY, function (e) {
        ...
    });

    // For opened and closed you can get which handler trigger the event.
    window.addEventListener(Gpn.constant.EVENT_OPENED, function (e) {
        var handler = e.detail;
        ...
    });

    Token IFrame - JavaScript Request Sample:

    We also export the variable Gpn.checkout so you can build your payment button via javascript. 

    

// input.js
var handler = Gpn.checkout.setup({
    locale: 'auto',
    keyboard: true,
    terms: 'http://www.yourbusiness.com/terms-and-conditons/',
    account: 'Your Business',
    accountDescription: 'The best business in the world.',
    accountLogoUrl: 'http://www.yourbusiness.com/logo.png',
    accountKey: 'your-public-key',
    currency: 'USD',
    orders: [
        {description: 'TV', price: 2000, quantity: 1},
        {description: 'Phone', price: 1000, quantity: 3}
    ],
    billingEnabled: true,
    shippingEnabled: true,
});

var buttonElem = document.getElementById('btn-pay');

buttonElem.addEventListener('click', function () {
    Gpn.checkout.open(handler, function(data) {
        // data contains the token and all options marked as Yes on Server....
        var token = data.token;
        ...
    });
});

    Server side

    After user complete the payment you will receive a token and payment information. With this token now you are able to make a transaction.

    The payment options are describe above but you will receive those one on camelcase.

    // server.curl
    <?curl
        $token = $_POST['token'];

    // Now you are able to make a transaction using this token.

    Server Side Response

    Charge succeed 

    

token: "71C03B0B-7AF8-461C-AEA4-A47439C4B093"
method: "card"
bin: "455660"
last4: "9680"
brand: "Visa"
billingEnabled: "true"
billingFirstname: "Jone"
billingLastname: "Doe"
billingEmail: "[email protected]"
billingPhone: "+48 123456789"
billingAddressLine1: "Avenue 21"
billingAddressLine2: ""
billingAddressPostalCode: "12-345"
billingAddressCity: "Oz City"
billingAddressState: "MZ"
billingAddressCountry: "PL"
shippingEnabled: "true"
shippingFirstname: "Jone"
shippingLastname: "Doe"
shippingEmail: "[email protected]"
shippingPhone: "+48 123456789"
shippingAddressLine1: "Avenue 21"
shippingAddressLine2: ""
shippingAddressPostalCode: "12-345"
shippingAddressCity: "Oz City"
shippingAddressState: "MZ"
shippingAddressCountry: "PL"
sameBillingShipping: "true"

    700 – Start Token Request (3DS Enabled)

    Description: Allows the merchant to submit a charge using TOKEN and includes 3DS capability when 3DS is specified in the Merchant Agreement.

    700 Request Data description:

    Node Include in Checksum (in this order) Optional Data Type Description
    apiUser YES (1) YES Character max 50. The API user assigned by the Gateway to the merchant. Can be obtained from the website inside your merchant account.
    apiPassword YES (2) YES Character max 50. The API password assigned by Gateway to the merchant. Can be obtained from the website inside your merchant account.
    apiCmd YES (3) YES 700 3 digit numeric transaction code must be 700
    transaction YES Xml Node Section containing Transaction Information
    transaction->merchanttransid YES (4) YES Character max 50. Merchant transaction id must be included in the request. Merchant transaction id must be unique for each transaction.
    transaction->amount YES (5) YES Number with point decimal Full amount to charge in currency specified. The amount must be specified as a number with decimal point and 2 digits to the right of the decimal point. Decimal separator must be point (.). example: 3500.25 = Three thousand five hundred units of currency and twenty five hundredths of a single unit of currency.
    transaction->curcode YES (6) YES Character 3. May only use currencies specified in the Merchant Agreement.
    transaction->description YES Character max 100. Description of the charge. When available, that description may be used in the billing statement of the card holder.
    transaction->merchantspecific1 OPT Character max 200. Merchant specific data for merchant use only. Data sent in this field will be stored and sent in any communication or response to the merchant.
    transaction->merchantspecific2 OPT Character max 200. Merchant specific data for merchant use only. Data sent in this field will be stored and sent in any communication or response to the merchant.
    transaction->merchantspecific3 OPT Character max 200. Merchant specific data for merchant use only. Data sent in this field will be stored and sent in any communication or response to the merchant.
    transaction->merchantspecific4 OPT Character max 200. Merchant specific data for merchant use only. Data sent in this field will be stored and sent in any communication or response to the merchant.
    transaction->merchantspecific5 OPT Character max 200. Merchant specific data for merchant use only. Data sent in this field will be stored and sent in any communication or response to the merchant.
    customer YES Xml Node Section containing Customer Information
    customer->firstname YES Character max 50. First name of the Customer.
    customer->lastname YES Character max 50. Last name of the Customer.
    customer->birthday YES* Number 1-2 digits Day of birth of the Customer (1-31) Important Note: If Merchant cannot provide such data, he/she should contact GPN’s Sales Account Manager. Tag will be set as “Optional” only with GPN’s Sales Account Manager approval.
    customer->birthmonth YES* Number 1-2 digits Month of birth of the customer (1-12) Important Note: If Merchant cannot provide such data, he/she should contact GPN’s Sales Account Manager. Tag will be set as “Optional” only with GPN’s Sales Account Manager approval.
    customer->birthyear YES* Number 4 digits Year of birth of the customer (1900-2100) Important Note: If Merchant cannot provide such data, he/she should contact GPN’s Sales Account Manager. Tag will be set as “Optional” only with GPN’s Sales Account Manager approval.
    customer->email YES Character max 100. Email of the Customer.
    customer->countryiso YES Character exactly 3. 3 letter ISO country code of the Customer. Full list of codes can be obtained from the website inside your merchant account.
    customer->stateregioniso YES Character max 3. 1-3 character ISO 3166 state/region/province code of the Customer. Full list of codes can be obtained from the website inside your merchant account.
    customer->zippostal YES Character max 15. Customer’s Zipcode or postal code.
    customer->city YES Character max 50. Customer’s City
    customer->address1 YES Character max 75. Customer’s address line 1
    customer->address2 OPT Character max 75. Customer’s address line 2
    customer->phone1phone YES Character max 20. Customer’s phone number, including country code and area code. Digits only, without (+) character
    customer->phone2phone OPT Character max 20. Customer’s phone number, including country code and area code. Digits only, without (+) character
    customer->accountid YES Character max 50. Customer unique account id used inside the merchant organization.
    customer->ipaddress YES Character max 15. Full IP address of the customer used for this transaction
    creditcard COND Xml Node Section containing sepa bank account Information. Required for sepa transactions, forbidden for credit card transactions.
    creditcard->cccvv YES (8) YES Character max 4. Verification Code of the Credit Card
    creditcard->token YES YES Character UUID v4 max 36. Unique id of instrument token. Required for retrieval by instrument token unique id
    checksum YES Character 36 SHA-1 calculated using the fields specified by the transaction plus the API key assigned by gateway to the merchant. This field must be calculated using the fields marked as “Include in checksum” (in the order indicated) plus the API key at the end.
    auth YES Xml Node Section containing authorization type
    auth->type YES Character max. 6 This tag Must be present. Valid values are Direct = non- 3DS Charge (Auth/Capture) Auth = non-3DS Auth Only 3DS = 3DS Charge (Auth/Capture) Auth3DS = 3DS Auth Only Note: only those choices available as indicated in the Merchant Profile are accepted.
    auth->sid COND Character no limit* This tag is used only during 3D Secure transactions. It is intended to use as a session identification string and it is forwarded to you as a part of your Return URL. (See Appendix for “3D Secure Integration”) Note: Keep in mind that URL length (your Return URL + SID) must be under 2 000 characters

    700 Token – Response

    The response to a 700-Start Credit card Charge Transaction is:
    • The completion of the transaction if the Merchant Agreement does NOT require 3DS.
    • The completion of the transaction if the Merchant Agreement DOES require 3DS and the Issuing Bank is NOT a 3DS participant.
    • The end of the first step for a 3DS transaction if the Issuing Bank IS a 3DS participant. The merchant must continue with the 705 command to complete the transaction IF the merchant receives a response from the redirect screen (see Appendix “3DS Explanation” for more information).

    Response Data description:

    Node Optional Data Type Description
    result YES Character Indicates the result of the transaction. SUCCESS: Customer’s Credit Card account has been charged (or AUTHORIZED) with the amount of the transaction. DECLINED: transaction was declined. ERROR: An error has been detected in the request. PENDING: If the Issuing bank has been determined to participate in the 3DS program, this is the normal response and it will include the PaReq and ACS data. The merchant must present a redirect screen to the cardholder, using the URL supplied in the ACS tag and supply the PaReq as a POST parameter. For further instructions see the Appendix “3DS Explanation”
    merchanttransid YES Character max 50. Unique merchant transaction id received in the request.
    transref COND Integer Gateway’s transaction reference number. Will be sent in the response only if the result is not ERROR. Merchant should save this reference number for support and troubleshooting.
    gatetransid COND Character 36 Gateway transaction ID. Will be sent in the response only if the result is not ERROR. Merchant should save this reference number for refunds and other transaction activity performed through API.
    errorcode YES Character 3 Error Code of the transaction or 000 if no error condition found.
    errormessage OPT Character max 100 Full description of the error.
    description OPT Character no limit Optional details of the transaction except in the case of DECLINED and then the reason for the decline. May be null.
    ACS NO Character string No limit Not present if not a 3DS transaction or if it is a 3DS transaction and the Issuing Bank is not a participant in the 3DS program. If present, this is the URL for the redirect screen (see Appendix “3DS Explanation”)
    parameters COND XML node Not present if not a 3DS transaction or if it is a 3DS transaction and the Issuing Bank is not a participant in the 3DS program. If present, ALL child elements must be transmitted in the redirect screen (see Appendix “3DS Explanation”)
    parameters ->PaReq COND Encoded character string no limit This string must be transmitted in the redirect screen (see Appendix “3DS Explanation”)
    parameters ->MD COND Character string max 50 This is the authorization process ID for the redirect screen (see Appendix “3DS Explanation”). It must be stored and forwarded in API Call 705
    parameters ->TermUrl COND Character string max 2000 This is the URL where Access Control Server sends response, which need to be forwarded to the Gateway. Depending on Acquiring bank this value may be different than 3DS Return URL provided by merchant
    parameters->… NO Character string Optional other parameters that must be transmitted in the redirect screen

    The 700 request is plain XML that contains the following data:

      <?xmlversion="1.0" encoding="utf-8" ?>
	<transaction>
	<apiUser> </apiUser>
	<apiPassword> </apiPassword>
	<apiCmd> </apiCmd>
		<transaction> 
			<merchanttransid> </merchanttransid>
			<amount> </amount>
			<curcode> </curcode>
			<description> </description>
			<merchantspecific1> </merchantspecific1>
			<merchantspecific2> </merchantspecific2>
			<merchantspecific3> </merchantspecific3>
			<merchantspecific4> </merchantspecific4>
			<merchantspecific5> </merchantspecific5>
		</transaction>
		<customer> 
			<firstname> </firstname>
			<lastname> </lastname>
			<birthday> </birthday>
			<birthmonth> </birthmonth>
			<birthyear> </birthyear>
			<email> </email>
			<countryiso> </countryiso>
			<stateregioniso> </stateregioniso>
			<zippostal> </zippostal>
			<city> </city>
			<address1> </address1>
			<address2> </address2>
			<phone1phone> </phone1phone>
			<phone2phone> </phone2phone>
			<accountid> </accountid>
			<ipaddress> </ipaddress>					
		</customer>
		<creditcard> 
			<cccvv> </cccvv>
			<token> </token>
		</creditcard> 	
		<checksum> </checksum>
		<auth> 
			<type> </type>
			<sid> </sid>
		</auth> 
	</transaction>

    The 700 response is plain XML that contains the following data:

    
	<?xmlversion="1.0" encoding="utf-8" ?>
	<transaction>
	<result> </result>
	<merchanttransid> </merchanttransid>
	<transref> </transref>
	<gatetransid> </gatetransid>
	<errorcode> </errorcode>
	<errormessage> </errormessage>
	<description> </description>
	<ACS> </ACS>
	<parameters> 
		<PaReq> </PaReq>
		<MD> </MD>
		<TermUrl> </TermUrl>
	</parameters> 
	</transaction>

    ERROR CODES

    Tokenization errors related to Merchant tokenization settings

    501 Merchant has no tokenization settings. Tokenization settings are created when options related to ‘Tokenization’ section of Merchant Profile -> API Integration -> Edit are being set for the first time.
    502 Merchant tokenization is not turned on. Enable it in Merchant Profile -> API Integration -> Edit -> ‘Merchant is tokenized’ at ‘Tokenization’ section.
    503 Creation of Tokens without binding is disabled. This error code is raised when Merchant attempts to send API 640 request without any <customer><accountid> value, but has no permissions to create unbound Tokens.
    504 Merchant is obliged to send <customer><accountid> along with request but request lacks this information. Refer to Merchant Profile -> API Integration -> Edit -> ‘Merchant Account ID is obligatory’ option at ‘Tokenization’ section.
    505 Merchant is not allowed to send <customer><accountid> along with request but request contains this information. Refer to Merchant Profile -> API Integration -> Edit -> ‘Merchant Account ID is allowed’ option at ‘Tokenization’ section.
    506 Merchant is obliged to send full <customer> section along with request but request lacks this information. Refer to Merchant Profile -> API Integration -> Edit -> ‘Customer data is obligatory’ option at ‘Tokenization’ section.
    507 Merchant is not allowed to send full <customer> section along with request but request contains this information. Refer to Merchant Profile -> API Integration -> Edit -> ‘Customer data is allowed’ option at ‘Tokenization’ section.

    Tokenization errors related to bad input data

    521 Transaction API request contains mismatched data resulting in undeterminable Token Customer data handling type (trnx tokenized only with MAID or with full customer data).
    522 Occurs when data context is missing, e.g. no <token> and no <customer> data for API 641 call.
    523 Occurs when data context is mixed, e.g. both Funding Instrument and full <customer> data for API 640 call.
    524 No <customer><accountid> information.
    525 Too many (more than one) <customer> sections in request.
    526 <customer> section exists in request, but is empty.
    527 <customer> section contains insufficient information (misses some required fields).
    528 Token of ID given in request is not found.
    529 Token of ID given in request had been deleted.
    530 Token of ID given in request has expired.
    531 Token of ID given in request is no longer usable (is one time Token and is already used).
    532 Token Customer of given MAID is not found.
    533 Not all Tokens with IDs provided in input are bound to the same Token Customer.
    534 Attempt to create Token Customer when already exists.
    535 Attempt to update Token Customer when not exists.
    536 Attempt to delete unbound (i.e. one-time, created for Iframe integration) Token.

    Tokenization errors consider as fraudulent

    551 Attempt to use Token belonging to other Merchant.
    552 Attempt to forge/exploit tokenization data.
    553 Attempt to use bad passkey (i.e. CSC).

    Tokenization errors considered as internal

    541 More than one unbound, not one-time and unexpired Token for Funding Instrument. DB integrity error, since this situation for proper operation should never happen.
    542 Merchant provided by auth could not be instantiated.
    543 Internal Token retrieval DB query error.
    544 Bad internal Token query arguments.
    545 Attempt to internally save Tokens of non-stored Token Customer.

    Funding Instrument errors, considered as internal since not exposed to API

    561 Internal attempt to alter stored Funding Instrument data (read-only violation).
    562 Internal attempt to retrieve Funding Instrument only by its ID (internal security violation).
    563 Funding Instrument pointed by Token is not found.
    564 No Merchant ID internally provided.
    565 Merchant of internally provided ID not found.
    566 No PAN internally provided.
    567 No ‘safe PAN’ internally provided.
    568 Internal query for Funding Instrument didn’t contain any argument.
    569 Internal query for Funding Instrument contain bad argument(s).
    570 No payment type internally specified.
    571 Wrong payment type internally specified.
    572 No funding type internally specified.
    573 Wrong funding type internally specified.
    574 Funding Instrument has no connection with internally given Token ID.