At TSYS, we use managed DNS services to provide global load balancing and data center redundancy. We publish our public IP addresses but we rely on DNS to make sure our customers are routed the to correct data centers at the correct times. Although it’s possible to use our public IP addresses directly, it would prevent us from managing uptime, balancing load, and supporting any network connectivity issues. Also, as we change ISPs (as we did in Q1 2017), ISVs and merchants may experience a loss of availability by circumventing DNS, as our IP addresses will change. We don’t recommend ISVs implement any custom load balancing or redundancy solutions but if you choose to, please be aware that we cannot assist or support you or your merchants in the design of such a system, nor in the operation thereof. Further, TSYS can make no guarantees around availability or uptime, as your solution would circumvent our global high availability system’s design.

TSYS is committed to providing the highest possible availability and best in class service. All of our systems are diverse, redundant, and highly available from our DNS providers to our ISPs, data centers, and every component and virtual machine within our data centers. We strongly believe that our mutual customers will benefit from your heeding the above guidance.

The TransportKey used to access a Genius CED or Transport.Web is a one time use, time sensitive token.

When performing multiple activities using a TransportKey, or if a timeout is encountered when communicating with a Genius CED or Transport.Web a new TransportKey must be obtained.

Merchants increasingly have both online and storefront environments. We are often asked whether merchants are required to have different MIDs for online vs. storefront, or if they can both use the same merchant account.

We recommend that merchants create separate MIDs for storefront vs. online transactions. The prevailing industry guidance is that merchants with an existing retail account can extend the merchant account to e-commerce, card not present transactions, within some limitations. Acquirers typically employ a "20% rule" where if a merchant has an existing Retail account - that is, the retailer should only process Card Not Present transactions up to 20% of their total sales. If a merchant exceeds the 20% rule, the account has a risk of downgrades and could possibly be shut down. When engaging with partners and merchants about unified commerce, it is best practice to consider this 20% rule to avoid these risks. When in doubt, opt to create distinct accounts for online vs. in store.

Even if merchants are using different MIDs online vs. in store, our Unified Commerce solution supports use cases like "buy online, return in store", allowing for a seamless customer and merchant experience across those two channels.

Please don’t hesitate to reach out to your relationship manager to further discuss risk management options.

Our Certification Engineering team will occasionally receive inquiries relating to the use of cURL for staging a Genius transaction. We have put together a few common examples that you may use as a reference for debugging purposes.

Stage Transaction

• Command Line Format: curl.exe https://transport.merchantware.net/v4/transportService.asmx -H "Content-Type:text/xml" -X POST -d @"StageTransaction.txt"
• Request Format

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
    <CreateTransaction xmlns="http://transport.merchantware.net/v4/">
    <merchantName>Zero Inc</merchantName>
    <merchantSiteId>00000000</merchantSiteId>
    <merchantKey>00000-00000-00000-00000-00000</merchantKey>
    <request>
        <TransactionType>SALE</TransactionType>
        <Amount>1.23</Amount>
        <ClerkId>ABC123</ClerkId>
        <OrderNumber>ABC123</OrderNumber>
        <Dba>ZERO BRANDS</Dba>
        <SoftwareName>ABC SOFTWARE</SoftwareName>
        <SoftwareVersion>1.0.0.0</SoftwareVersion>
        <Cardholder>VISA TEST CARD</Cardholder>
        <TransactionId>ABC123</TransactionId>
        <ForceDuplicate>false</ForceDuplicate>
        <CustomerCode>ABC123</CustomerCode>
        <PoNumber>ABC123</PoNumber>
        <TaxAmount>0.10</TaxAmount>
        <TerminalId>01</TerminalId>
        <HealthCareAmountDetails>
            <HealthCareTotalAmount>0.00</HealthCareTotalAmount>
            <ClinicalAmount>0.00</ClinicalAmount>
            <CopayAmount>0.00</CopayAmount>
            <DentalAmount>0.00</DentalAmount>
            <PrescriptionAmount>0.00</PrescriptionAmount>
            <VisionAmount>0.00</VisionAmount>
        </HealthCareAmountDetails>
        <TipDetails>
            <EligibleAmount>0.00</EligibleAmount>
        </TipDetails>
    </request>
</CreateTransaction>
</soap:Body>
</soap:Envelope>

Initiate Transaction

• Command Line Format: curl.exe "http://[CED IP Address]:8080/v2/pos?TransportKey=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx&Format=XML"

Retrieve Transaction Details

• Command Line Format: curl.exe https://genius.merchantware.net/v1/Reporting.asmx -H "Content-Type:text/xml" -X POST -d@"Details.txt"
• Request Format

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <DetailsByTransportKey xmlns="http://schemas.merchantwarehouse.com/genius/10/Reporting">
    	<merchantName>Zero Inc</merchantName>
    	<merchantSiteId>00000000</merchantSiteId>
    	<merchantKey>00000-00000-00000-00000-00000</merchantKey>
    	<TransportKey>xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx</TransportKey>
    </DetailsByTransportKey>
  </soap:Body>
</soap:Envelope>

MasterCard has announced that they have received an additional range of 2-series (222100-272099) BIN numbers and card issuing banks may be assigned the new BIN ranges starting January 2017. The new BIN series will be processed in the same way as their existing 5-series (510000-559999) BIN ranges.

What is a BIN?

The BIN (bank identification number) is the first six digits or first eight digits of the card number printed on the front of the card. It identifies the card issuing institution. If the card number is less than 16 digits, only the first six digits are considered the BIN. If the card number is 16 or more digits, then the first eight digits are considered the BIN. The remainder of the card number is the account number that is assigned by the card issuing bank.

Do you support the new MasterCard BIN Range?

Yes, we have updated our solutions and APIs to support the new MasterCard BIN range. All of our integrated POS partners will automatically get support for the new BIN range without making changes to their POS integration, ultimately, providing support for the new BIN range to their respective merchants.

Does my POS require supporting Stored Value (Gift) Cards?
Stored Value (Gift) cards are great for attracting consumers and driving incremental bottom line revenue. Gift card sales have increased steadily over recent years, and demand remains incredibly strong.

Many ISV’s have a target audience for which their point of sale system will cater to, and depending on the payment types the merchant wishes to accept, support for Gift transactions may not be an immediate option. Often, merchants who are using an integrated point of sale system will inquire about accepting Gift transactions upon signing with TSYS.

To reduce potential costly development work at a later point, and reduce downtime for merchants, TSYS requires that new or existing ISV’s integrating to our Genius API include support for Gift processing. Gift card functionality will be reviewed during the implementation process and is a requirement aimed at providing a seamless integration for both developers as well as mutual merchants across all forms of the Genius API.

Please reach out to your Sales Engineer or the Certification Engineering team for any questions you may have with regards to your Genius integration.

DNS Hostname

Locating the DNS Hostname

• From the Idle screen, press "0 0 0" (zero-zero-zero) on the keypad
• Enter the Admin password: 9416557
• Press the green Enter button
• The Hostname will be displayed on the screen
• Pressing the red Cancel button will return you back to the Idle screen

IP Address

Locating the IP Address

• From the Idle screen, press "0 0 0" (zero-zero-zero) on the keypad
• Enter the Admin password: 9416557
• Press the green Enter button
• The IP Address will be the first item displayed
• Pressing the red Cancel button will return you back to the Idle screen

Configuring Static IP Address

• From the Idle screen, press "0 0 0" (zero-zero-zero) on the keypad
• Enter the Admin password: 9416557
• Press the green Enter button
• Tap Network
• Tap Configure
• Select Static as the IP Mode
• Enter the IP Address you wish to assign to the Genius device
  • For an IP Address such as 10.0.0.1, enter the values as 010.000.000.001
  • For an IP Address such as 192.168.0.1, enter the values as 192.168.000.001
• Continue entering the Netmask, Gateway, DNS 1 & DNS 2 values according to your network configuration
  • If you make a mistake while keying this information, use the yellow Back button
• Tap Save once all the values have been entered
• Pressing the red Cancel button will return you back to the Idle screen

Genius version 5.0 and later supports a HTTPs interface in addition to its traditional HTTP interface. Only the protocol scheme (https vs. http) and port (8443 vs 8080) differ from traditional Genius implementations. All other details regarding how your POS communicates with the terminal are unchanged - all API calls, URIs, messages, and request/response payloads are identical, excepting the protocol scheme and port. For more details, please see&Alternate Device Communication Methods in our Genius documentation.

Genius supports a HTTPS interface so users can communicate with the CED using TLS to secure the connection. Combined with Genius's CORS support, this feature is especially useful for partners who have developed browser based Points of Sale. The terminal will generate appropriate certificates as required in order to serve the TLS connection, and all certificates generated by the CED will be signed by the Cayan CA.

This means that if merchants install the Cayan CA, then their client machines will trust the certificates that are served by the terminal.

There are 2 Root Certificates for Genius devices. Which you need depends on the device you are using.

Version 1 Legacy Certificate (MX915, MX925): Cayan_1

Version 2 Device Certificate (P400, E285): prod_ca

Installation instructions differ between Operating Systems and Browsers, but installation is generally straight forward. Generally, you just need to download the certificate, double click it, and follow the prompts on your screen.

Installation instructions are provided below for some major Windows-based browsers. Firefox appears to use its own local certificate store, while Internet Explorer and Chrome appear to use the standard Windows certificate store. This means that if your POS is a desktop application, you will probably need to follow the Internet Explorer / Chrome installation instructions.

firefox

Go to https://docs.tsysmerchant.com/Site/Media/Docs/Site-Content/Cayan_1.crt

If you see:

Then you've already got the Cayan CA installed and you don't have anything further to do. Otherwise, you'll see:

Ensure that "Trust this CA to identify websites" is checked, then click "OK", and you're done.

Internet Explorer / Chrome

Go to https://docs.tsysmerchant.com/Site/Media/Docs/Site-Content/Cayan_1.crt and you'll be offered to download the Cayan.crt file, download it and save it somewhere on your hard drive.

Locate the file on your hard drive and right-click on it and choose "Install Certificate".

Select to install the certificate on the local machine and click next.

When asked "Windows can automatically select a certificate store, or you can specify a location for the certificate", choose "Place all certificates in the following store" and hit "Browse":

When prompted, choose "Trusted Root Certification Authorities" and click "OK":

Then click "Next" on the following screen.

Finally click "Finish" to complete the installation.

As a security measure, many merchants restrict outbound communications from their networks - whitelisting traffic to just a handful of sites, such as their payment processor.

Below are all the necessary details for how a Network Administrator should configure his/her networks and firewalls to inter-operate with TSYS's services.

The below diagram, excerpted from our Genius PA-DSS Eligibility Assessment, illustrates a common workflow between the Genius credit card terminal ("PED"), our Gateway, and the ISV's Point of Sale.

1. The user initiates a transaction, and the third-party software sends a payment request with the amount and other information (but no cardholder data) to the Gateway.
2. The gateway responds with a transport key.
3. The third-party software sends the transport key to the PED using HTTP.
4. The PED uses the transport key to retrieve the purchase amount from the Gateway.
5. Cardholder data is collected by the PED and encrypted.
6. The PED sends the encrypted data to the Gateway protected with HTTPS.
7. The transaction response (e.g., authorized, declined) and other information is sent to the PED.
8. The transaction response and other information is passed back to the third-party software.

Hosts:

• transport.merchantware.net
• genius.merchantware.net
• ps1.merchantware.net
• s01.merchantware.net
• logupload.merchantware.net

TSYS employs BGP in its data centers, which means that each of our data centers is served by multiple ISPs that advertize the same IP address ranges. By employing multiple ISPs in its data centers, TSYS can better protect its services from internet outages and traffic disruptions and provide higher uptimes and faster transactions for our customers. If you whitelist outbound traffic, you may want to whitelist the below IP ranges as a precautionary measure:

• Chicago: 209.133.97.0 /24
• Boston:   209.119.131.0 /24

Public internet:

• 443: SSL
• 7622: SFTP (via SSH)

Local area network:

• 8080: POS (or Store & Forward) communication to a Genius terminal (HTTP)
• 8443: POS communication to a Genius terminal (HTTPS)
• 7500: default Store & Forward for all traffic represented by transport.merchantware.net
• 7501: default Store & Forward for all traffic represented by ps1.merchantware.net
• 7502: default Store & Forward for all traffic represented by genius.merchantware.net
• 7503: default Store & Forward for Rest API that can be used to communicate with Store and Forward
• 7504: default Store & Forward that services the Administration Website

Genius will reach out to our Certificate Authority (Digicert) in order to perform certificate revocation checks, and otherwise validate certificates, to prevent against "man in the middle" attacks. If you see traffic on your network to "*.digicert.com", that's what this is, and you may want to whitelist those domains.

If your POS uses Genius over HTTPs and you do not have GlobalSign's root and intermediate certificates in your certificate store, you may need to install those. See GlobalSign's site for more details.

As you lock down your network, you may run into issues, and prevent your Point of Sale from being able to communicate with our gateway, thus preventing your merchants from processing credit card transactions. We recommend that network engineers read this document, as well as ours Service Availability Monitoring Best Practices guide, for how to test that their networks can communicate with TSYS.

We recommend that network engineers confirm that they can load the health check pages mentioned in the Service Availability Monitoring guide. Please confirm that your network can communicate with both of our data centers. We recommend that you run sequential tests, statically configuring DNS (eg. by modifying your hosts file) to point at our Boston and then Chicago data centers. Alter your DNS to force traffic to our Boston Data Center. Using a web browser running on your POS, confirm that you can load our health check pages. Then, modify your DNS to use our Chicago IP addresses, and re-confirm that you can load our health check pages.

If you encounter troubles connecting to TSYS's environment, please try repeating your test, using some neutral 3rd party site (eg. Google, Facebook, LinkedIn, ...). Once that is working, compare & contrast those settings with those you've implemented for TSYS's network.

We also suggest repeating any failed tests from an unrestricted network (eg. connected to a 4G LTE network) to help determine if the root cause is more likely to be with your network configuration than TSYS's. If you can connect from an unrestricted network, please examine your restricted network's configuration to ensure that all of NAT rules and ACLs are set up properly.

We also suggest using various common network troubleshooting tools & procedures to help diagnose any issues:

• nslookup & ping - to ensure that you've resolved our FQDNs properly
• traceroute - to ensure that your packets are making it to our data centers
• telnet - to make a quick connection to our IP addresses
• WireShark - to spy on your Point of Sale's traffic, and ensure that all TCP & SSL/TLS handshakes are occurring as expected

Warning: statically configuring DNS is only acceptable in a test/lab environment. TSYS manages its availability using a DNS load balancing algorithm, with a low TTL. TSYS requires its merchants and ISVs to use public DNS to.resolve our FQDNs. Not doing so will void any SLAs that may be in place, and will likely lead to downtime outside of TSYS's control.

Chicago IPs

209.133.97.100 ps1.merchantware.net
209.133.97.107 genius.merchantware.net
209.133.97.108 transport.merchantware.net
209.133.97.60 s01.merchantware.net
209.133.97.110 logupload.merchantware.net

Boston IPs

209.119.131.100 ps1.merchantware.net
209.119.131.107 genius.merchantware.net
209.119.131.108 transport.merchantware.net
209.119.131.110 logupload.merchantware.net
209.119.131.60 s01.merchantware.net

TSYS's products are presently only available in the North American marketplace. As a security measure, we've restricted inbound traffic to IP addresses in the USA and Canada. If you attempt to access our services outside of these countries - or from known public VPNs - your traffic may be blocked. We understand many of our partners have overseas development and testing teams who will need need access to our payment gateway. In these cases, we request that you reach out to your Sales Engineer or Business Development Manager to whitelist your IP addresses.

Tokens are a way to work with cards and transactions without actually having the card number. They can allow you to void transactions, repeat a sale, look up info, or save a card for later use.
However, there are a few different types of tokens you may encounter. Below are a list of the different kinds of tokens and what you can do with them.

Transaction Reference Number (Transaction Token)

This is the token that is returned with any transaction. You may also see this referred to as the PN Reference Number (PNRef). These tokens open up a range of functionality such as voiding, refunding, and capturing.
Gateway accounts can also be grouped together for Reference Number sharing. This will allow a call from one account to utilize tokens from the other. For instance, if a customer bought something from Store A but went to return them item at Store B, Store B would be able to use the original sale token to run a refund, so long as the two locations were "grouped" with each other. This allows a business to provide a customer with a unified commerce experience between different store locations and any online stores they may have.

Reference Number Use: Merchantware 4.5

To make use of a Reference Number in the MerchantWare 4.5 API, you need to define the Source tag as PREVIOUSTRANSACTION and the Token tag as the Reference Number you want to use inside the PaymentData object of your transaction request.

Example Previous Transaction SOAP Request

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
   <soap:Body>
      <Refund xmlns="http://schemas.merchantwarehouse.com/merchantware/v45/">
         <Credentials>
            <MerchantName>Zero Inc</MerchantName>
            <MerchantSiteId>00000000</MerchantSiteId>
            <MerchantKey>00000-00000-00000-00000-00000</MerchantKey>
         </Credentials>
         <PaymentData>
            <Source>PreviousTransaction</Source>
            
            <!--Previous Transaction Field-->
            <Token>608957</Token>
         </PaymentData>
         <Request>
            <InvoiceNumber>1703</InvoiceNumber>
            <RegisterNumber>35</RegisterNumber>
            <MerchantTransactionId>165902</MerchantTransactionId>
            <CardAcceptorTerminalId>3</CardAcceptorTerminalId>
         </Request>
      </Refund>
   </soap:Body>
</soap:Envelope>

Below are the calls that use a Reference Number.

For more information, see the MerchantWare 4.5 documentation.

Vault Token

The Vault is a way to store a card so it can be later used through the Vault Token generated, unlocking Card on File functionality for a business.

Vault Token Use: Merchantware 4.5

To make use of a Reference Number in the MerchantWare 4.5 API, you need to define the Source tag as VAULT and the Token tag as the Vault Token you want to use inside the PaymentData object of your transaction request.

Example Vault SOAP Request

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
   <soap:Body>
      <Sale xmlns="http://schemas.merchantwarehouse.com/merchantware/v45/">
         <Credentials>
            <MerchantName>Zero Inc</MerchantName>
            <MerchantSiteId>00000000</MerchantSiteId>
            <MerchantKey>00000-00000-00000-00000-00000</MerchantKey>
         </Credentials>
         <PaymentData>
            <Source>Vault</Source>
            
            <!--Vault Fields-->
            <VaultToken>1000000000002AVGMM7Z</VaultToken>
         </PaymentData>
         <Request>
            <Amount>1.83</Amount>
            <CashbackAmount>0.00</CashbackAmount>
            <SurchargeAmount>0.00</SurchargeAmount>
            <TaxAmount>0.00</TaxAmount>
            <InvoiceNumber>1559</InvoiceNumber>
            <PurchaseOrderNumber>17809</PurchaseOrderNumber>
            <CustomerCode>23</CustomerCode>
            <RegisterNumber>35</RegisterNumber>
            <MerchantTransactionId>166909</MerchantTransactionId>
            <CardAcceptorTerminalId>3</CardAcceptorTerminalId>
            <EnablePartialAuthorization>False</EnablePartialAuthorization>
            <ForceDuplicate>False</ForceDuplicate>
         </Request>
      </Sale>
   </soap:Body>
</soap:Envelope>

Below are the calls that use a Vault Token.

For more information, see the MerchantWare 4.5 documentation.

One Time Use Genius Checkout Token

The Genius Checkout Single Use Token functions a bit differently from the other token types. This token is not tied to a card number or a completed transaction, this token is tied to a transaction that has yet to be run. It is meant to be used only once to run the transaction it was created for, much like a Transport Key, and will expire in two minutes. While the format of a Checkout token will be the same as a Vault token, know that they are separate and will only function as per their actual source.

The Genius Countertop terminals can be powered either via AC current or via Power Over Ethernet (PoE). Included in the table below are representative power requirements that TSYS observed in its lab for Verifone V4 hardware models, as would be deployed in a P2PE environment. The power requirements measured between AC and PoE tended to be within 1W of each other. The MX925 series was observed to have higher Wattage requirements, as it has a larger screen than a MX915. Please note that using PoE with your Genius terminal requires a specialized I/O block, available from TSYS and Verifone. Please reach out to your Sales Engineer to ensure that you receive the necessary equipment.
 

Power over Ethernet or PoE describes any of several standardized or ad-hoc systems which pass electric power along with data on twisted pair Ethernet cabling. This allows a single cable to provide both data connection and electric power to devices such as wireless access points, IP cameras, and VoIP phones.
 
The original IEEE 802.3af-2003 PoE standard provides up to 15.4 W of DC power (minimum 44 V DC and 350 mA) on each port. Only 12.95 W is assured to be available at the powered device as some power dissipates in the cable. The updated IEEE 802.3at-2009 PoE standard also known as PoE+ or PoE plus, provides up to 25.5 W of power for "Type 2" devices. The 2009 standard prohibits a powered device from using all four pairs for power. Both of these amendments have since been incorporated into the IEEE 802.3-2012 publication.
 
Employing Power over Ethernet brings several advantages to an installation:

• Time and cost savings - by reducing the time and expense of having electrical power cabling installed.  Network cables do not require a qualified electrician to fit them, and can be located anywhere.
• Flexibility - without being tethered to an electrical outlet, devices such as IP cameras and wireless access points can be located wherever they are needed most, and repositioned easily if required.
• Safety - POE delivery is intelligent, and designed to protect network equipment from overload, underpowering, or incorrect installation.
• Reliability - POE power comes from a central and universally compatible source, rather than a collection of distributed wall adapters.  It can be backed-up by an uninterruptible power supply, or controlled to easily disable or reset devices.
• Scalability - having power available on the network means that installation and distribution of network connections is simple and effective.

If your environment provides insufficient power to the payment terminals, you may notice anomalous behavior, such as the terminals unexpectedly rebooting. TSYS recommends that all network engineers employ the following best practices when deploying payment terminals in a PoE environment:

• Provide sufficient power to the remote powered device. This may sound simple, but in practice, it is difficult. The IEEE 802.3af standard identifies four possible power classifications. At maximum, the powered remote device can draw up to 12.95 watts of power. Factoring loss through the length of the cable, this means that, at maximum, the power-sourcing equipment must have the ability to provide 15.4 watts of power to each port. In a 24-port Ethernet switch or midspan device, this means that approximately 370 watts of power must be available to supply the necessary power to each port. For the Ethernet switches, additional power above and beyond that required for PoE must be available for its switching functions.
• Provide sufficient power to the remote powered device – by ensuring that they’re plugged into the right ports. Many switches will offer several “tiers” of power to PoE devices – for example, they may offer both 4W ports and 15.4W ports. Many smaller devices (eg. web cameras or microphones/speakers) have lower power requirements than payment terminals. Ensure that your payment terminals are plugged into ports that support the power requirements outlined above.
• Connect the power source to uninterruptible and redundant power. The remote devices fed by PoE typically are mission-critical devices. For instance, an IP phone that loses power is a lost voice circuit. Think about that for a moment. Regardless of whether it is a traditional circuit-switched analog phone or an IP phone, it is a lifeline circuit. It has to work. You must consider how you are going to design your network to ensure that consistent and reliable data transfer and power are maintained to this critical device. Connect the critical power-sourcing devices to an uninterruptible power supply, and use devices with dual redundant power supplies to ensure that your critical devices never lose power.
• Pay attention to cabling-performance specifications. What Category rating does your cabling infrastructure have? Most likely, this is Category 5e or 6.
• Pay attention to cabling length. PoE will only power the unit so long as there is enough voltage to power the unit at the end of the cable run. The maximum distance you can power a device will vary depending on the access point and its voltage required, as well as the voltage provided by the power supply, and the quality of the cable. Cat6 cable is recommended for long POE runs. For passive POE you should use a 24V power supply. 24V passive POE will power an OM series AP up to about 50 meters or 100-150 feet. 48V 802.3af standard POE can usually go about 100 meters/300 feet.       

Genius Splashscreen

00 Idle screen

01 Retrieving (Please Wait)

02 Payment Selection

03 Custom payment collection

04 Looking up card BIN

![Code 04: Looking up card BIN](https://developer.globalpaymentsintegrated.com/portal/web/sites/default/files/inline-images
/p400_binlookup.png)

05 Waiting for amount confirmation

06 Waiting for PIN entry

07 Processing payment

![Code 07: Processing payment](https://developer.globalpaymentsintegrated.com/portal/web/sites/default/files/inline-images
/p400_emv_processing.png)

08 Waiting for signature

09 Processing signature capture

10 Transaction result

![Code 10: Transaction result approved](https://developer.globalpaymentsintegrated.com/portal/web/sites/default/files/inline-images
/p400_approved.png) ![Code 10: Transaction result declined](https://developer.globalpaymentsintegrated.com/portal/web/sites/default/files/inline-images
/p400_declined.png)  ![Code 10: Transaction result failed](https://developer.globalpaymentsintegrated.com/portal/web/sites/default/files/inline-images
/p400_failed.png)

11 Cancel confirmation

12 Run as credit confirmation

13 SKU display

14 Cashback selection screen

15 Cashback custom screen

16 Tip selection screen

17 Tip custom screen

18 Donation selection screen

19 Donation custom screen

20 Confirmation screen

23 EBT Selection

24 Error screen

26 SKU amount confirmation screen

27 PAN entry screen

28 Expiration entry screen

29 CVV entry screen

30 Zip entry screen

31 Agreement screen

32 Agreement signature screen

33 EMV application selection screen

35 Get customer input screen

36 Gift Card Capture Screen

38 Network details screen

![Code 38: Network options screen](https://developer.globalpaymentsintegrated.com/portal/web/sites/default/files/inline-images/
p400_admin_network_options_config.png)  ![Code 38: Network overview screen](https://developer.globalpaymentsintegrated.com/portal/web/sites/default/files/inline-images/
p400_admin_network_overview.png) 

39 Network configuration screen

42 Admin Screen

43 Admin Overview

![Code 43: Admin overview](https://developer.globalpaymentsintegrated.com/portal/web/sites/default/files/inline-images
/p400_admin_overview.png)

45 Admin Network Test

51 Card Collision

![Code 51: Card collision](https://developer.globalpaymentsintegrated.com/portal/web/sites/default/files/inline-images
/p400_card_collision.png)

52 Card Removed Too Early

53 Ceiling Limit Exceeded

![Code 53: Ceiling limit exceeded](https://developer.globalpaymentsintegrated.com/portal/web/sites/default/files/inline-images/
p400_card_removed_too_early.png)

61 Error: Please Remove Card

65 Admin Network Test Details

65 Contactless Unavailable

67 Contactless Unavailable for Gift

69 Acquiring Card Presence

71 Bad Swipe

![Code 71: Bad swipe](https://developer.globalpaymentsintegrated.com/portal/web/sites/default/files/inline-images
/p400_bad_swipe.png)

72 Chip Temporarily Unavailable

![Code 72: Chip temporarily unavailable](https://developer.globalpaymentsintegrated.com/portal/web/sites/default/files/inline-images
/p400_chip_temporarily_unavailable_swipe.png)

As a security mechanism Genius CED devices are paired to merchant credentials using the device serial number. Because of this, production merchants will have devices configured to their account prior to shipment to the merchant location. Test devices used for integration will also be paired to your specific Genius test account.

If you are integrating to a physical device and receiving this error verify the credentials being used to perform the test transactions. If you are still experiencing difficulty contact the Certification Engineering team at the developer@cayan.com email address. 

If a device needs to be moved from one merchant account to another, please contact us at the partnersupport@cayan.com email address. 

The PCI Security Standards Council is a global forum for the ongoing development, enhancement, storage, dissemination and implementation of security standards for account data protection.

PCI Security Standards are technical and operational requirements set by the PCI Security Standards Council (PCI SSC) to protect cardholder data. The standards apply to all entities that store, process or transmit cardholder data – with requirements for software developers and manufacturers of applications and devices used in those transactions. The Council is responsible for managing the security standards, while compliance with the PCI set of standards is enforced by the founding members of the Council, American Express, Discover Financial Services, JCB, MasterCard and Visa Inc.

The Payment Card Industry Data Security Standard (PCI DSS) is a set of security standards designed to ensure that ALL entities that accept, process, store or transmit credit card information maintain a secure environment. It covers technical and operational system components included in or connected to cardholder data. If you accept or process payment cards, PCI DSS applies to you.

For more information on PCI, the PCI SSC, and PCI DSS, please see:

1. https://www.pcicomplianceguide.org/pci-faqs-2/
2. https://www.pcisecuritystandards.org/

There are up to three tracks on magnetic cards known as tracks 1, 2, and 3. Track 3 is virtually unused by the major worldwide networks, and often isn't even physically present on the card by virtue of a narrower magnetic stripe. Point-of-sale card readers almost always read track 1, or track 2, and sometimes both, in case one track is unreadable. The minimum cardholder account information needed to complete a transaction is present on both tracks. Track 1 has a higher bit density (210 bits per inch vs. 75), is the only track that may contain alphabetic text, and hence is the only track that contains the cardholder's name.

Track 1 is written with code known as DEC SIXBIT plus odd parity. The information on track 1 on financial cards is contained in several formats: A, which is reserved for proprietary use of the card issuer, B, which is described below, C-M, which are reserved for use by ANSI Subcommittee X3B10 and N-Z, which are available for use by individual card issuers:

Track 1, Format B:

• Start sentinel — one character (generally '%')
• Format code="B" — one character (alpha only)
• Primary account number (PAN) — up to 19 characters. Usually, but not always, matches the credit card number printed on the front of the card.
• Field Separator — one character (generally '^')
• Name — two to 26 characters
• Field Separator — one character (generally '^')
• Expiration date — four characters in the form YYMM.
• Service code — three characters
• Discretionary data — may include Pin Verification Key Indicator (PVKI, 1 character), PIN Verification Value (PVV, 4 characters), Card Verification Value or Card Verification Code (CVV or CVC, 3 characters)
• End sentinel — one character (generally '?')
• Longitudinal redundancy check (LRC) — it is one character and a validity character calculated from other data on the track.

Track 2: This format was developed by the banking industry (ABA). This track is written with a 5-bit scheme (4 data bits + 1 parity), which allows for sixteen possible characters, which are the numbers 0-9, plus the six characters  : ; < = > ? . The selection of six punctuation symbols may seem odd, but in fact the sixteen codes simply map to the ASCII range 0x30 through 0x3f, which defines ten digit characters plus those six symbols. The data format is as follows:

• Start sentinel — one character (generally ';')
• Primary account number (PAN) — up to 19 characters. Usually, but not always, matches the credit card number printed on the front of the card.
• Separator — one char (generally '=')
• Expiration date — four characters in the form YYMM.
• Service code — three digits. The first digit specifies the interchange rules, the second specifies authorisation processing and the third specifies the range of services
• Discretionary data — as in track one
• End sentinel — one character (generally '?')
• Longitudinal redundancy check (LRC) — it is one character and a validity character calculated from other data on the track. Most reader devices do not return this value when the card is swiped to the presentation layer, and use it only to verify the input internally to the reader.

Service code values common in financial cards:

First digit

1: International interchange OK

2: International interchange, use IC (chip) where feasible

5: National interchange only except under bilateral agreement

6: National interchange only except under bilateral agreement, use IC (chip) where feasible

7: No interchange except under bilateral agreement (closed loop)

9: Test

Second digit

0: Normal

2: Contact issuer via online means

4: Contact issuer via online means except under bilateral agreement

Third digit

0: No restrictions, PIN required

1: No restrictions

2: Goods and services only (no cash)

3: ATM only, PIN required

4: Cash only

5: Goods and services only (no cash), PIN required

6: No restrictions, use PIN where feasible

7: Goods and services only (no cash), use PIN where feasible

Knowing what to print on a merchant & customer receipt isn't a simple task - navigating the varying different requirements of the different card brands and issuing banks requires a lot of effort and detailed analysis. By following our best practice guide which collates the different requirements from the various card brands and issuing banks into an easy to follow matrix, you'll ensure that your merchants' receipts can be used as evidence in any chargeback process.

Magnetic Stripe & Keyed Transaction Receipt Requirements

Below are VISA's Transaction Receipt Requirements for Card-Present and Card-Absent Merchants.

EMV Receipt Requirements

The below receipt requirements for EMV transactions are in addition to the general MSR credit card receipt requirements outlined above. These requirements also apply to receipts issued for declined transactions should you choose to provide them to your customer.

Example EMV Receipt

What About TSYS's Electronic Receipts?

TSYS's Virtual Terminal portal provides electronic receipts that can be used to dispute a chargeback. These receipts meet the card brands' requirements for both MSR and EMV transactions. In the case of merchants using TSYS's Genius CED, these receipts contain a electronic signature and are retained for a period of 18 months. While TSYS provides an electronic copy of the receipt available to merchants, partners' points of sale are required to produce a compliant receipt for your merchants' cardholders.

For merchants who perform card-present transactions but do not use Genius and whose Point of Sale does not transmit a digitally captured signature to TSYS, these receipts will not have a digital signature, which is often used as part of the chargeback dispute & resolution process. TSYS recommends that these merchants retain a signed physical paper copy of their merchant receipt in their records for a period of 18 months.

To send a Zero Dollar Authorization, or Account Number Verification, use the PREAUTH transaction type with a $0 amount.

PCI requires that all systems used by parties processing Cardholder Data be patched and supported by their respective vendors. Merchants not using a supported Operating System will not be PCI compliant, and must update to a supported Operating System.

Below is a table of common POS Operating Systems released by Microsoft, and their respective support dates.