My Profile_

Understanding and Using This Specification

Interpreting this Specification

If merchants are uncertain about the interpretation or applicability of a particular requirement or best practice as stated as in this specification, it is their responsibility to contact their Moneris Client Integration Specialist to obtain clarification.

Requirements

Requirements are identified throughout the document as three types: either they are indicated by as “Requirement”, “Best Practice”, or “Note”.

Best Practices

Best practices use the words “should” or “may” if they are positive statements, and “should not” if they are suggestions to avoid certain behaviours or states. Best practices are recommendations only, and merchants are not obligated to implement them. Note that best practices, being at the merchant’s discretion, may not be tested during the Moneris approval process.

Transaction Records and Receipts

This section covers the requirements and recommendations for cardholder transaction records (CTRs), merchant copy receipts, and cardholder receipts. It also provides definitions and explanations for required CTR and receipt elements, and samples of printed merchant copy and cardholder receipts.

Definitions

Cardholder receipt A cardholder receipt is the printed receipt provided to a cardholder at the time of the transaction.
Merchant (copy) receipt A merchant (copy) receipt is a printed or electronic copy of the transaction that contains specific information not found on the cardholder receipt that is defined later in this section.
Cardholder Transaction Record (CTR) A cardholder transaction record (CTR) is a collection of data specific to a transaction that is a subset of all possible transaction data, such that the collection of data is sufficient to produce a cardholder or merchant (copy) receipt.

General Requirements

The following are requirements covering Cardholder Transaction Records , merchant copy receipts, and cardholder receipts.

Receipt Differences (USA and Canada)

Requirements
  • Canadian solutions must be able to print receipts in both offcial languages (English and French). U.S.A. receipts are English only.
  • Interac receipts are applicable to Canadian applications only. Moneris does not support Interac in the U.S.A.

Best Practice
  • Address information on Canadian receipts uses Province and Postal Code. U.S.A. receipts use State and ZIP code.
  • Canada and the U.S.A. use different terminology for some transaction types (see table below).
    Canada US
    Purchase Sale
    Correction Void
  • The U.S.A. receipt contain a section for AVS, CVD, CVV2, CVC and CID. Canadian receipts to do not have this section.
  • Level 2 Commercial Card data collected in the US must be displayed on the cardholder receipt. Canadian receipts to do not have this section.

Cardholder Transaction Record

Requirements
  • The merchant must create a Cardholder Transaction Record (CTR) for the following transactions, and must store each CTR for a minimum of twenty-four months:
    • Purchase
    • Refund
    • Purchase Correction
    • Pre-authorization
    • Pre-authorization Completion
  • The merchant must create and store a CTR for all transactions that produce transaction data, regardless of whether the transaction is approved or declined.
  • For reversal transactions, the merchant must save an indicator with the original (reversed) transaction’s CTR, which identifies the type of reversal (Time-Out, Declined by Card, or Customer-Initiated) that occurred.
  • The terminal must print separate receipts for each partially approved transaction, or the terminal must print one receipt for the entire purchase where multiple partially approved transactions are processed. Each financial transaction must be distinctly identified with required data.
  • If the terminal does not support a PED for cardholder prompts, the cardholder receipt must print the account balance amount if returned by the issuer.
  • For all UnionPay transactions, the terminal must print a receipt with a cardholder signature line as all UnionPay transactions require a cardholder signature.

Merchant Copy Receipt

Requirements
  • Merchants must store transaction data either by:
    • saving printed merchant copy receipts, or,
    • by saving electronic records.
  • If the merchant stores transaction data by saving electronic records, then they must save sufficient Cardholder Transaction Record information (i.e., a subset of all possible transaction data) along with the means to reproduce the full merchant copy receipt, such that the merchant can reproduce the full merchant copy receipt upon request.
  • For credit transactions processed to a SAF file, the merchant must save a manual imprint of the cardholder credit card along with the merchant copy receipt.
  • The account balance must never be printed on the merchant copy when a balance inquiry is requested by a cardholder.

Cardholder Receipt

Requirements
  • Moneris supports some programs that allow for the suppression of printed cardholder receipts. For example, some contactless programs do not require receipt printing. For these programs, although the merchant can, in general, avoid printing a receipt, the merchant must be able to print a receipt at the request of the cardholder.
  • The merchant must configure their terminals to default in favour of receipt printing. That is, the merchant must always print a cardholder receipt unless receipt printing is suppressed according to a supported program.
  • The merchant must not print the following elements on the cardholder receipt:
    • the merchant number
    • the expiration date of the card
    • any confidential or personal cardholder information other than the elements defined in this section
  • The terminal must have the ability to re-print a (duplicate) cardholder receipt for the last transaction processed, whether approved or declined.
  • At unattended terminals, the cardholder must be prompted at the beginning of the transaction whether or not to have a receipt printed at the end of transaction processing (i.e., “Yes” or “No”). If no entry is made by the cardholder, the terminal must default to "Yes" and must print a receipt.
  • The terminal may support printing the account balance on the receipt for the cardholder where the external PED is available but the cardholder requests the receipt.
  • The receipt must show each partially approved transaction.
  • The account balance must only be printed on the cardholder copy of the receipt and must not be printed on the merchant copy.

Best Practice
  • In the event a balance inquiry cannot be displayed to cardholder, only the cardholder copy can be printed with balance information.

Merchant/Cardholder Copy Signature Requirements

The merchant must ensure that receipt copies are signed according to the payment scheme requirements listed in the table below.
Receipt signature requirements
VISA MasterCard Amex/JCB
MERCHANT COPY SIGNED BY… CARDHOLDER COPY SIGNED BY… MERCHANT COPY SIGNED BY… CARDHOLDER COPY SIGNED BY… MERCHANT COPY SIGNED BY… CARDHOLDER COPY SIGNED BY…
PURCHASE Cardholder n/a Cardholder n/a Cardholder n/a
PURCHASE CORRECTION Cardholder n/a n/a n/a Cardholder n/a
REFUND Cardholder n/a n/a n/a Cardholder n/a
PRE-AUTH Cardholder n/a Cardholder n/a Cardholder n/a
PRE-AUTH COMPLETION n/a n/a n/a n/a n/a n/a
Discover Union Pay
MERCHANT COPY SIGNED BY… CARDHOLDER COPY SIGNED BY… MERCHANT COPY SIGNED BY… CARDHOLDER COPY SIGNED
BY…
PURCHASE Cardholder n/a Cardholder n/a
PURCHASE CORRECTION n/a Merchant Cardholder n/a
REFUND n/a Merchant Cardholder n/a
PRE-AUTH Cardholder n/a Cardholder n/a
PRE-AUTH COMPLETION n/a n/a Cardholder n/a

Language Requirements

Requirements
  • If the necessary information is available to determine the cardholder’s language as English or French (i.e., from magnetic stripe data, chip data, or an optional bilingual cardholder prompt), the terminal must print the cardholder receipt in that language. If the terminal cannot determine the cardholder language, then the language of the terminal must be used for the cardholder receipt.
  • The terminal must print the merchant receipt in the language of the terminal.

Best Practice
  • The Requirement above for language notwithstanding, if the terminal cannot determine the cardholder language, then the terminal may print a bilingual cardholder receipt, rather than default to the terminal language for the cardholder receipt.
  • The terminal should print receipts using the translation table given below. Note: Accents are mandatory for lower case characters.
Card Transaction Record translation table
ENGLISH FRENCH
ACCOUNT BALANCE SOLDE DISPONIBLE
ACCOUNT TYPE COMPTE
AUGUST (AUG.) AOUT (AOUT)
AMOUNT MONTANT
AMOUNT DUE MONTANT DU
APPROVAL APPROUVÉE
APPROVED - THANK YOU APPROUVÉE - MERCI
APRIL (APR.) AVRIL (AVRIL)
AUTHORIZATION AUTORISATION
BALANCE INQUIRY INTERROGATION DE SOLDE
CARD NUMBER NUMÉRO CARTE
CASHBACK REMISE D’ARGENT
CASHIER CAISSIÈRE
CHEQUING CHÈQUE
CHIP CARD CARTE À PUCE
CHIP CARD KEYED CARTE À PUCE TAPÉE
CHIP CARD SWIPED CARTE À PUCE GLISSÉE
CHIP CARD MALFUNCTION DÉFAILLANCE CARTE À PUCE
COMPLETION AVIS D'ACHAT
DATE DATE
DECEMBER (DEC.) DÉCEMBRE (DÉC.)
DEFAULT DÉFAUT
EXPIRY DATE DATE EXPIRÉE
FALLBACK REPLI
FEBRUARY (FEB.) FÉVRIER (FÉVR.)
GST TPS
INVOICE FACTURE
JANUARY (JAN.) JANVIÉR (JANV.)
JULY (JULY) JUILLET (JUIL.)
JUNE (JUNE) JUIN (JUIN)
MARCH (MAR.) MARS (MARS)
MAY (MAI) MAI (MAI)
NO SIGNATURE REQUIRED SIGNATURE NON REQUISE
NOVEMBER (NOV.) NOVEMBRE (NOV.)
OCTOBER (OCT.) OCTOBRE (OCT.)
PARTIAL APPROVAL AUTORISATION PARTIEL
PRE-AUTH AUTORISATION
PST TVQ
PURCHASE ACHAT
PURCHASE CORRECTION CORRECTION D'ACHAT
RECEIPT RELEVÉ
REFERENCE NUMBER NUMÉRO RÉFÉRENCE
REFUND REMISE D'ACHAT
REFUND CORRECTION CORRECTION DE REMISE
SALE (internet only) VENTE (internet seulement)
SAVINGS ÉPARGNE
SEPTEMBER (SEPT.) SEPTEMBRE (SEPT.)
SIGNATURE SIGNATURE
TIME HEURE
TIP POURBOIRE
TRANSACTION OPÉRATION
TRANSACTION CANCELLED OPÉRATION ANNULÉE
TRANSACTION NOT APPROVED OPÉRATION REFUSÉE
TRANSACTION NOT COMPLETED OPÉRATION NON COMPLÉTÉE See Approval/Decline Messages
TRANSACTION RECORD RELEVÉ DE TRANSACTION
VERIFIED BY PIN VÉRIFIÉE PAR NIP

eCommerce Cardholder Receipt Requirements

Cardholder receipts for eCommerce transactions have specialized requirements due to the nature of the Internet card not present (CNP) environment.

Requirements
  • The merchant must provide the customer with a receipt as a record of the transaction, either by electronic means such as an email or by surface mail if physical goods are being sent.
  • The merchant must not send cardholder account data over the Internet to the customer. Instead, the merchant must use a unique identification number (which must also appear on the cardholder receipt) to associate the transaction with cardholder account details.
  • The merchant must include the relevant URL (Uniform Resource Locator) or Internet address on the Cardholder Transaction Record.
  • The merchant must provide a description of the purchased goods and/or services on the cardholder receipt.
  • The merchant must include a list of any restrictions for refunds or returns related to the transaction on the cardholder receipt.
  • The merchant must include the name of the company that performed the transaction with the customer on the cardholder receipt. The merchant must not substitute the Internet Provider’s name for the appropriate company name.
  • The merchant must include the transaction amount, the currency of the transaction, and the authorization code on the cardholder receipt.
    Best Practice
    • Where practical, the merchant should use the Moneris sequence/reference number that is returned in the response message as the transaction’s unique identification number.

    • Masking

    Requirements
    • The merchant must ensure that all but the last four digits of the card number (debit or credit) are “masked” (i.e., replaced with the asterisk character [*]) on both the cardholder receipt and the merchant Cardholder Transaction Record, whether paper or electronic. The merchant must not print or store additional digits of the PAN. Note that the number of asterisks present must be such that the number of asterisks plus the number of visible digits equals the actual length of the PAN.

    Masking usually presents as in the following example: *************1234

    Unattended Terminals

    For unattended terminals, the cardholder interacts with an automated system to process a transaction. Transactions currently supported for unattended terminals include the following:

    • Purchase
    • Pre-authorization/Pre-authorization Completion (processed as a single transaction from the cardholder's perspective)
    • Reversal
    Requirements
    • Merchants must ensure that transaction records and receipts from unattended terminals meet the following requirements:
      • Cardholder Transaction Records produced for unattended terminals must meet the same requirements as for attended terminals
      • cardholder receipts must be printed unless the cardholder indicates via a terminal prompt that a receipt is not desired
      • a printed cardholder receipt for an unattended terminal includes all of the same elements as for an attended terminal, with the following conditional additions:
        • If the CVM is PIN entry, the PIN entry indicator must be printed
        • If a chip malfunction occurs on a MasterCard transaction, "Chip Card Malfunction" must be printed

    Cardholder Transaction Record and Receipt Definitions

    English and French Receipt Layouts

    The following diagram shows all of the printed information required for financial transactions. Note that the requirements for individual receipt elements assumes that the terminal supports functionality for the element; for example, requirements for the "Tip" element defined as element number 7 is only relevant for transactions and terminals that support Tip functionality.

    Requirements
    • The merchant must adhere to all requirements described in the table below concerning the printing of receipts. Note that “conditional” items, i.e., those that depend on a condition based on the nature of the transaction or of the merchant configuration, become “mandatory” if the condition applies.


    LINE

    ELEMENT

    PROGRAM/TRANSACTION

    DESCRIPTION

    1

    Receipt Header

    Mandatory for Interac, recommended for all other cards and transactions.

    TRANSACTION RECORD/RELEVE DE TRANSACTION

    CTR = not used

    Merchant receipt = mandatory

    Cardholder receipt  = mandatory

    2

    Merchant Name

    All cards and transactions  

    The name of the merchant as stored on the host in the terminal language (no translation is required).

    CTR = not used

    Merchant receipt = mandatory

    Cardholder receipt  = mandatory

    3

    Store Address

    All cards and transactions

    The postal address of the merchant location, including street, town/city, province, and postal code. Address appears as stored on the host in the terminal language (no translation is required).

    CTR = not used

    Merchant receipt = mandatory

    Cardholder receipt  = mandatory

    4

    Transaction Type

    All cards and transactions

    Type of transaction, for example, Purchase.

    For AFDs (pay at the pump), the transaction type must be PURCHASE, not PRE‑AUTHORIZATION, even if the originating transaction was a pre-authorization that was completed when the cardholder finished pumping their fuel.

    CTR = mandatory

    Merchant receipt = mandatory

    Cardholder receipt  = mandatory

    5

    Card Name

    All cards and transactions

    The name of the card as obtained during the initialization transaction in DIDs 0-99, such as: VISA, MASTERCARD, INTERAC, AMERICAN EXPRESS, JCB, DISCOVER or UNIONPAY.

    The value of the card name for Interac in DIDs 0-99 (where Interac is identified by card type [P]) must be printed as received (i.e., as “INTERAC”). The word “DEBIT” must not be printed in place of “INTERAC” as the card name for Interac transactions.

    CTR = mandatory

    Merchant receipt = mandatory

    Cardholder receipt  = mandatory

    6

    Account Type

     

    Interac  transactions

    For swiped or inserted Interac transactions, print CHEQUING or SAVINGS.

    For Interac Flash, print FLASH DEFAULT/DEFAUT FLASH.

    Otherwise this area can be blank.

    CTR = mandatory

    Merchant receipt = mandatory

    Cardholder receipt  = mandatory

    7

    Amount

    All cards and transactions

    The base amount of the transaction.

    CTR = mandatory

    Merchant receipt = mandatory

    Cardholder receipt  = mandatory

    8

    Partially Approved

    Purchase and pre-authorization transactions

    The partially approved amount of the transaction that has been authorized by the issuer.

    9

    Amount due

    Purchase and pre-authorization transactions

    The purchase amount due after issuers have returned an authorization response with an approval for a portion of the original amount requested, enabling the remainder of the transaction amount to be paid by other means using split tender functionality where applicable.

    10

    Tip

    All cards, used only for purchase and pre-authorization completion transactions

    Tip amount added by cardholder, typically used by service industry merchants where tips are accepted (restaurants, salons, and so on).

    If no tip amount is entered in the transaction, this area must be blank or must not appear.

    CTR = mandatory

    Merchant receipt = mandatory

    Cardholder receipt  = mandatory

    11

    Cashback

    Interac cards on purchase transactions (Note: domestic Visa Debit cashback is not printed separately but included as part of Amount)

    Cashback amount added to the transaction where the terminal is enabled for cashback. If no cashback amount is entered in the transaction, this area must be blank or must not appear. Cashback must not be supported for tapped Interac Flash transactions.

    CTR = mandatory

    Merchant receipt = mandatory

    Cardholder receipt  = mandatory

    12

    Surcharge

    Interac cards on purchase transactions

    The amount of any surcharge charged by the Acquirer.

    CTR = mandatory

    Merchant receipt = mandatory

    Cardholder receipt  = mandatory

    13

    Total

    All cards and transactions where tip and/or cashback are present

    Total value of the transaction (base amount plus tip and/or cashback and any applicable taxes). Taxes must be identified as: GST / TVF, HST / TVH, and so on.

    CTR = mandatory

    Merchant receipt = mandatory

    Cardholder receipt  = mandatory

    14

    Acct Balance (cardholder copy only)

    All cards (except Interac) used for purchase, pre-authorization and balance inquiry transactions

    The Balance Inquiry or Partially Approved Transaction will indicate the available account balance on a cardholder account (except Balance Inquiry for JCB).

    CTR = not used

    Merchant receipt = do not be print on merchant copy

    Cardholder receipt = optional if displayed to customer on PED

    15

    Dynamic Currency Conversion (DCC) details

    For transactions using DCC.

    RATE* will be printed for purchase, purchase correction, refund correction and pre-auth completion. TODAYS RATE* will be printed for pre-auth transaction.

    BASE RATE will be printed for refund transaction (see 2.7.3 Dynamic Currency Conversion Receipts)

    CTR = mandatory

    Merchant receipt = mandatory

    Cardholder receipt = mandatory

    16

    Dynamic  Currency Conversion (DCC) details

    For VISA DCC only.

    CTR = not used

    Merchant receipt = mandatory

    Cardholder receipt = mandatory

    17

    Card Number

    All cards and transactions  

    Cardholder PAN with masking.

    CTR = mandatory

    Merchant receipt = mandatory

    Cardholder receipt  = mandatory

    18

    Date/Time

    All cards and transactions

    The date and time of the transaction in any format provided that it includes day, month, year, and time (in 24 hour format). Time is recommended to include seconds in order to improve tracing. The date/time printed must be the data returned from the Moneris Host.  Note that if the transaction times-out, the POS terminal timestamp must be used.

    CTR = mandatory

    Merchant receipt = mandatory

    Cardholder receipt  = mandatory

    19

    Reference Number

    All cards and transactions

    A unique transaction ID that includes the following elements:

    60101944

    terminal number

    001

    shift

    001

    batch number

    001

    serial number

    0

    control flag (0 or 1)

    CTR = mandatory

    Merchant receipt = mandatory

    Cardholder receipt  = mandatory

    20

    Card Entry Method

    All cards and transactions

    Must appear immediately after the reference number as a single letter identifier for card entry. Note that the full word (e.g., “Swiped” or “Tapped”) must not be used.  Only the single letter abbreviation is acceptable:

    S

    Swiped

    card is swiped, and

    transaction is not EMV fallback

    M

    Manually Entered

    card is manually keyed, and

    transaction is not EMV fallback

    C

    Chip Card Reader

    card is inserted, and

    transaction completes an approved or declined EMV transaction or non-EMV transaction using EMV functionality

    T

    Tapped

    Card/NFC device is tapped, and  transaction is MSD

    H

    Tapped

    Card/NFC device is tapped, and transaction is EMV

    F

    Fallback Swiped

    EMV contact-based chip card is swiped at the fallback prompt, and

    the transaction completes an approved or declined fallback transaction

    G

    Fallback Manually Entered

    EMV contact-based chip card is manually entered at the fallback prompt

    the transaction completes an approved or declined fallback transaction

    CTR = mandatory

    Merchant receipt = mandatory

    Cardholder receipt  = mandatory

    21

    Authorization #

    All cards, for Approved transactions only

    Authorization number appears only on approved transactions.

    CTR = mandatory

    Merchant receipt = mandatory

    Cardholder receipt  = mandatory

    22

    Application Label

    All EMV transactions and non-EMV transactions using EMV functionality

    If neither the Application Label nor the Application Preferred Name is available/printable, then the Card Name as provided in the initialization transaction (not the Card Type) must be printed.

    Required only if the Application Preferred Name is not available.

    If used, this field must be printed, unaltered, as provided by the card.

    CTR = mandatory

    Merchant receipt = mandatory

    Cardholder receipt  = mandatory

    23

    Application Preferred Name

    All EMV transactions and non-EMV transactions using EMV functionality

    Must be printed when it is available, readable, and only makes use of Code Table Index 01 (i.e., Latin-1 / standard ASCII).

    If used, this field must be printed, unaltered, as provided by the card.

    CTR = mandatory

    Merchant receipt = mandatory

    Cardholder receipt  = mandatory

    24

    EMV AID

    All EMV transactions and non-EMV transactions using EMV functionality

    The AID selected during EMV Application Selection. This is a binary field and must be printed in ASCII hexadecimal format.

    CTR = mandatory

    Merchant receipt = mandatory

    Cardholder receipt  = mandatory

    25

    Terminal Verification Results

    All EMV transactions, except Visa payWave qVSDC transactions

    This must be the final TVR as it exists at the completion of the EMV transaction.

    It is a binary field and must be printed in ASCII hexadecimal format (10 characters).

    It must not be printed for Visa payWave transactions.

    CTR = mandatory

    Merchant receipt = mandatory

    Cardholder receipt  = mandatory

    26

    Transaction Status Information (TSI)

    All EMV transactions.

    The TSI should not be printed if it is not supplied by the kernel during transaction processing.

    The TSI is a binary field and must be printed in ASCII hexadecimal format (4 characters).

    It must be printed whenever the TVR is printed.

    CTR = mandatory

    Merchant receipt = mandatory

    Cardholder receipt  = mandatory

    27

    EMV Reversal Message

    EMV transactions where card declined the issuer’s approved response

    If a reversal is required because the chip card declined a host-approved transaction or because the chip card was removed prematurely, the appropriate message must be printed along with the Moneris Host response code, DECLINED BY CARD-990 or CARD REMOVED-991.

    CTR = not used

    Merchant receipt = mandatory

    Cardholder receipt  = mandatory

    28

    PIN Entry Indicator

    All contact-based EMV transactions

    If an EMV transaction is approved where PIN verification is the CVM, the text VERIFIED BY PIN must be printed.  

    CTR = mandatory

    Merchant receipt = mandatory

    Cardholder receipt  = do not print on cardholder receipt unless unattended

    29

    Fallback Message

    All contact-based EMV transactions and non-EMV transactions using EMV functionality that fall back to magnetic stripe or manual entry

    If a fallback transaction is approved for a chip card that was swiped, the text CHIP CARD SWIPED / CARTE A PUCE GLISSEE must be printed. If the fallback is approved for a chip card that was manually entered, the text CHIP CARD KEYED / CARTE A PUCE TAPEE must be printed.

    CTR = not used

    Merchant receipt = mandatory

    Cardholder receipt  = mandatory

    30

    Chip Card Malfunction

    MasterCard issued contact-based chip cards where chip technology fails after the request message has been sent

    The text CHIP CARD MALFUNCTION/ DÉFAILLANCE CARTE À PUCE only applies to approved transactions and must be printed in smaller type than the APPROVED/APPROUVÉE message text.

    CTR = mandatory (an indicator is stored)

    Merchant receipt = mandatory

    Cardholder receipt  = must not be printed on cardholder receipt unless unattended

    31

    Transaction Partially Approved

    All cards (except Interac) used for purchase and pre-authorization transactions

    If transaction is partially approved, the message “TRANSACTION PARTIALLY APPROVED/AUTORISATION PARTIELLE DE LA TRANSACTION” must be printed.

    CTR = mandatory

    Merchant receipt = mandatory

    Cardholder receipt  = mandatory

    32

    Invoice Number

    All cards and transactions

    Identifies an invoice number associated with the transaction. This element must be stored/printed whenever an invoice number is sent by the merchant as part of the request message. If no invoice number is entered in the transaction, this area must be blank or must not appear.

    CTR = mandatory

    Merchant receipt = mandatory

    Cardholder receipt  = mandatory

    33

    Promo Code

    Credit transactions where Private Label cards are enabled

    Identifies a promotional code supported by the card. This field is required only for private label transactions.

    CTR = mandatory

    Merchant receipt = mandatory

    Cardholder receipt  = mandatory

    34

    ISO Response Code

    All cards, all transactions except reversals, cancelled, and timed-out transactions

    It is recommended, though not required, that the ISO Response Code appear immediately before the Approval/Decline message.

    The ISO Response Code must not be printed on reversal receipts.

    CTR = mandatory (excluding reversals, cancelled, and timed-out transactions)

    Merchant receipt = mandatory

    Cardholder receipt  = mandatory

    35

    Approval/Decline

    All cards and transactions

    Refer to the list of Approval/Decline messages provided below.

    CTR = not used

    Merchant receipt = mandatory

    Cardholder receipt  = mandatory

    36

    Moneris Response Code

    All cards all transactions except reversals, cancelled,  and timed-out transactions

    It is recommended, though not required, that the Moneris Response Code appear immediately after the Approval/Decline message.

    The Moneris Response Code must not be printed on reversal receipts.

    CTR = mandatory (excluding reversals, cancelled, and timed-out transactions)

    Merchant receipt = mandatory

    Cardholder receipt  = mandatory

    37

    Assisted UnionPay Transaction Indicator

    All transactions processed as an assisted UnionPay transaction

    For UnionPay magstripe transactions where SFID 9K = “UP” in the request message, “UnionPay” will print on the transaction receipt

    38

    FF / DT (Form Factor/Device Type)

    Purchase, Pre-Auth, Pre-Auth Completion, Card Verification, and Balance Inquiry, when provided by the card.

    Form Factor/Device Type values in ASCII hex. The FF/DT will be printed on the merchant copy of the receipt when provided by the “card”. If FF/DT is not provided by the card, then the entire line ‘FF/DT’ will not be printed see "Form Factor and Device Type" below

    39

    Signature Line

    All credit cards, on transactions requiring a signature

    See Signature Requirements

     

    40

    Cardholder Agreement

    All credit cards, on credit transactions

    The cardholder agreement statement is conditional on signature for Purchase, Pre-Authorization, and Refund Correction transactions, i.e., it must be printed on the merchant receipt copy if the transaction requires signature. It is not applicable for other transactions or CVMs other than signature.

    The text CARDHOLDER WILL PAY CARD ISSUER ABOVE AMOUNT PURSUANT TO CARDHOLDER AGREEMENT / LE TITULAIRE VERSERA CE MONTANT A L'EMETTEUR CONFORMEMENT AU CONTRACT ADHERENT must be printed.

    CTR = not used

    Merchant receipt = conditional on signature

    Cardholder receipt  = optional

    41

    Retention Statement

    All credit transactions, on credit transactions

    The following text must be printed: "IMPORTANT - retain this copy for your records" / "IMPORTANT - conserver cette copie pour vos dossiers".

    CTR = not used

    Merchant receipt = optional

    Cardholder receipt  = mandatory

    42

    Copy Indicator

    All cards and transactions

    A printed receipt must be labelled as "Merchant Copy" "Cardholder Copy" or "Duplicate". A duplicate receipt will always be a cardholder receipt.

    CTR = not used

    Merchant receipt = mandatory

    Cardholder receipt  = mandatory


    Form Factor and Device Type

    The form factor indicator (FFI), also know as device type for MasterCard, describes the chip card technology used to make payment. Examples of form factors include plastic cards, key fobs, subscriber identity modules (SIMs) used in mobile phones, and USB-based tokens.

    Table CTR_Form_Factor_T01: Form Factor and Device Type by Card Brand.

    Card Brand

    Obtain from Card

    Sent to Host

    American Express

    9F70 and/or 82

    FID 9U Tag FF10, Byte 1-2

    MasterCard

    9F6E

    FID 9U Tag 9F6E, Byte 5-6

    Visa

    9F6E

    FID 9U Tag 9F6E, Byte 1

     

    Requirement: The terminal must use tags 82 and 9F70 to identify that the mobile form factor is tapped for Amex transactions. If tag 9F70 byte 1 bit 4 is 1, and/or tag 82 byte 2 bit 7 is 1, the terminal must populate tag FF10 with a value of 03. In all other cases tag FF10 must be populated with 00. The value of ‘03’ identifies mobile phone and the value of ‘00’ identifies contactless card.


    Approval/Decline Messages

    The examples in the table below identify required message language and the application of ISO codes and response codes for different kinds of transaction outcomes. Note that "99" represents the ISO code returned with the message, and "XXX" represents the response code from Moneris. In the event of an acquirer stand-in, the ISO code sent to the card may be different from the code received from the host. The ISO response code returned from the host should be printed on the receipt.

    English and French receipt requirements for various response codes

    MESSAGE FOR

    ENGLISH

    FRENCH

    Approval

    99 Approved - Thank You XXX

    99 Approuvee - Merci XXX

    Cancellation

    Transaction Cancelled

    Opération Annulée

    Partial Authorization Cancellation by Merchant or Cardholder

    Partial Authorization Cancelled

    Autorisation Partiel Annulé

    Terminal time-out

    Transaction Not Completed

    Opération non Complétée

    Reversal

    Transaction Not Completed

    Opération non Complétée

    Store and forward (SAF)

    Approved - Thank You

    Approuvée - Merci

    Debit card declines returned with any of the following ISO codes:

    05

    51

    54

    55

    57

    58

    61

    62

    65

    75

    82

    92

    99 Transaction Not Approved XXX

    99 Opération Refusée XXX

     

    Debit card declines not specified by ISO code, as above

    99 Transaction Not Completed XXX

    99 Opération non Complétée XXX

    Credit card declines where the Base24 response code corresponds with data from DID O or DID P

    99 Transaction Not Completed XXX

    99 Opération non Complétée XXX

    Credit card declines not specified by a response code downloaded in DID O or DID P

    99 Transaction Not Approved XXX

    99 Opération Refusée XXX

    Receipt Samples

    This section provides samples of merchant and cardholder receipts resulting from less common processing occurrences. The purpose of this section is to clarify the requirements for receipts that are less typical, or occur rarely in the course of normal processing.

    Best Practice
    • The merchant may use the sample printouts in the following sections as guidelines for fulfilling the requirements defined in the Cardholder Transaction Record and Receipt Definitions above, but the section Cardholder Transaction Record and Receipt Definitions requirements always take precedence and must be followed correctly in all cases.

    Contactless Transaction Receipts (With and Without Signature Line)

    The following receipts show that a contactless card tapped at a terminal may or may not require a signature CVM. These examples are all shown in English and labelled as "merchant copy" and "cardholder copy".

    Tapped Card - Signature Required
    Tapped Card - No Signature Required


    Language of the Application Preferred Name

    The following receipts show that the Application Preferred Name on an EMV credit transaction may not appear as English or French. The element is printed as provided by the card.

    Merchant Copy Receipts
    Cardholder Copy Receipts

    MasterCard Chip Malfunction

    The following receipts show an approved EMV MasterCard purchase with a chip malfunction. MasterCard requirements specify that if a response message is returned with an approval, and then the chip malfunctions, the transaction must not be declined as a result of the chip malfunction.

    Merchant Copy Receipts

    Cardholder Copy Receipts

    Cancelled Debit Refund

    The following receipts are examples from a debit refund transaction when the transaction is cancelled. If the transaction has been started and then cancelled after cardholder data has been entered but before the cardholder has entered the PIN for verification, a receipt must be printed. Note that the timestamp for this receipt is from the terminal and not from the Moneris Host. EMV data, if available, should be printed.

    Merchant Copy Receipts
    Cardholder Copy Receipts

    The cardholder receipt appears the same as the merchant receipt above, except the copy indicator element says "Cardholder Copy".

    Not Completed Transaction

    The following receipts are examples of Not Completed transaction types. If the transaction has been started and then cancelled after cardholder data has been entered (but before the cardholder has entered the PIN for verification, if necessary), a receipt must be printed. Note that the timestamp for this receipt is from the terminal and not from the Moneris Host. EMV data, if available, should be printed.

    Merchant Copy Receipt – Transaction Not Completed
    Cardholder Copy Receipt – Transaction Not Completed
    Merchant Copy Receipts – Reversal/Timeout
    Cardholder Copy Receipts – Reversal/Timeout
    Cardholder Copy Receipts – Declined by Card
    Cardholder Copy Receipts – Declined by Card
    Cardholder Copy Receipts – Card Removed
    Cardholder Copy Receipts – Card Removed

    Transaction Not Approved

    The following receipts are examples of Not Approved transaction types, where the transaction is not approved. If the transaction has not been approved, a receipt must be printed. Note that the timestamp for this receipt is from the terminal and not from the Moneris Host. EMV data, if available, should be printed.

    Merchant Copy Receipts – Transaction Not Approved

    NOTE:
    XX = ISO RESPONSE CODE
    XXX = MONERIS RESPONSE CODE

    Cardholder Copy Receipts – Transaction Not Approved

    NOTE:
    XX = ISO RESPONSE CODE
    XXX = MONERIS RESPONSE CODE

    eCommerce Cardholder Transaction Record

    This record may be provided electronically (by email), or by posted mail. Requirements for the cardholder transaction record (CTR) differ for eCommerce transactions, as follows:

    • the customer must be provided a record of the transaction (signatureless and no-receipt-required programs do not apply with eCommerce)
    • account data must not be sent over the Internet to the customer
    eCommerce Receipt (Canada)
      

    NOTE

    TITLE

    DESCRIPTION

    1

    Merchant Name

    The name of the merchant. Note that this is not the name of the internet service provider, but the legal name of the merchant. 

    2

    Store Address

    The postal address of the merchant location, including street, town/city, province, and postal code.

    3

    Merchant URL

    The web address for the merchant. This field is mandatory for an eCommerce transaction. 

    4

    Transaction Type

    The type of transaction processes, for example: Purchase.

    5

    Order Number

    Optional, at the merchant's discretion. 

    6

    Date/time of Transaction

    The date of the transaction, in any format provided it includes day, month, year, and the time in 24-hour format. 

    7

    Authorization Number

    Authorization number appears only on approved transactions.

    8

    Reference Number

    Unique identification number used to retrieve account details later. This number is the made up of the terminal number and the sequence number. 

    9

    Response / ISO Code

    Response code and ISO code returned for the transaction.

    10

    Goods Description

    A description of the goods and/or services provided to the customer. This field is mandatory for an eCommerce transaction. 

    11

    Amount

    Total amount of the transaction cardholder.

    12

    Currency Code

    The currency code must appear on an eCommerce CTR. 

    13

    Cardholder Information

    The name and address of the cardholder.

    14

    Restrictions

    List any restrictions on customer refunds and returns. This field is mandatory for eCommerce transactions.
    REQUIRED FOR INTERAC ONLINE ONLY

    15

    Issuer Name

    Name of the institution that provided the Interac card.

    16

    Issuer Confirmation

    Number from online banking which is displayed on the confirmation page.

    17

    Invoice Number

    A meaningful invoice number populated by merchant.

    Hotel Cardholder Transaction Record

    A guest folio provided to a cardholder at a hotel is a form of cardholder transaction record with specific requirements. The following provides a definition for a guest receipt. Note that this is a sample to be used for guideline purposes.

    NOTE

    TITLE

    DESCRIPTION

    1

    Merchant Name

    The name of the merchant (hotel).

    2

    Store Address

    The postal address of the hotel, including street, town/city, province, and postal code.

    3

    Check-in Date

    The date the cardholder checked into the hotel.

    4

    Check-out Date

    The date the cardholder checks out of the hotel.

    5

    Checked-in By

    The clerk who checked the cardholder into the hotel, opening the transaction.

    6

    Checked-out By

    The clerk who checked the cardholder out of the hotel, closing the transaction.

    7

    Room Rate

    The amount charged per the merchant's arrangement.

    8

    Description of Charges

    A detailed list of charges applied.

    9

    Total Amount

    Total amount of the transaction.

    10

    Currency

    The country currency associated with the charge.

    11

    Card Number

    Cardholder PAN with masking.

    12

    Card Type

    For Interac transactions, print CHEQUING or SAVINGS.

    For credit card transactions or Visa Debit transactions, print the card name, such as: VISA, MASTERCARD, AMERICAN EXPRESS, VISA DEBIT, and so on.

    13

    Transaction Date/Time

    The date and time of the transaction in any format provided that it includes day, month, year, and time (in 24 hour format). Time is recommended to include seconds in order to improve tracing. The date/time returned in the SPDH heard (or ISO DE48), response message, is used as the CTR timestamp. Note that if the transaction times-out, the POS terminal timestamp is used.

    14

    Transaction Type

    Type of transaction, for example, Purchase.

    15

    Total

    Total amount of the transaction.

    16

    Authorization Number

    Authorization number appears only on approved transactions.

    17

    Reference Number

    A unique transaction ID that includes the following elements:

    60101944

    ECR number

    001

    shift

    133

    batch number

    001

    serial number

    0

    control flag (0 or 1)

    18

    Card Entry Method

    Appears immediately after the reference number as a single letter identifier for card entry. Refer to the main CTR Definition for the list, including S (swiped), M (manually entered), and so on. 

    19

    Transaction Approval Message

    Refer to the list of Approval/Decline messages provided in the main CTR Definition section. 

    20

    Cardholder Signature

    The cardholder is required to sign only for the merchant copy. Note that signature line is not required for contact-based chip cards in EMV environment where a cardholder signature is not required. 

    21

    Cardholder Agreement Message

    The cardholder agreement statement is optional for Purchase, Pre-Authorization, Pre-Authorization Completion, and Refund Correction transactions. 

    Mail Order / Telephone Order

    The following sample is for a merchant copy receipt in English and French for a MOTO purchase.

    Cancelled Transaction – AFD and Service Stations only

    The following samples are used to identify AFD and Service Station requirements for cancelled transaction receipts.

    COPYRIGHT

    © 2000-2016 Moneris Solutions, 3300 Bloor Street West, Toronto, Ontario, M8X 2X2

    All Rights Reserved. This manual shall not wholly or in part, in any form or by any means, electronic, mechanical, including photocopying, be reproduced, stored in a retrieval system, or transmitted without the authorized consent of Moneris Solutions.

    Moneris Solutions reserves the right to revise this document and to periodically make changes to the content hereof without obligation of notification of such revisions or changes unless required to do so by prior agreement.

    DISCLAIMER

    Neither Moneris Solutions Corporation (Moneris) nor any of its affiliates shall be liable for any direct, indirect, incidental, consequential or punitive damages arising out of use of any of the information contained in this document. Neither Moneris or any of its affiliates nor any of our or their respective licensors, licensees, service providers or suppliers warrant or make any representation regarding the use or the results of the use of the information, content and materials contained in this guide in terms of their correctness, accuracy, reliability or otherwise.

    NOTICE OF CONFIDENTIALITY

    This document contains information that is the proprietary and confidential property of Moneris Solutions. The recipient agrees to maintain this information in confidence and not reproduce or otherwise disclose this information.

    TRADEMARKS

    Moneris and the Moneris Solutions logo are registered trademarks of Moneris Solutions Corporation. All other marks or registered trademarks are the marks or registered trademarks of their respective owners.

    MasterCard®, PayPass™, and M/Chip® are trademarks or registered trademarks of MasterCard International. Visa®, Visa payWave™, Visa Debit®, and VSDC® are trademarks or registered trademarks of Visa International. Interac® and Flash® are registered trademarks of Interac, Inc. American Express®, AEIPS®, and ExpressPay® are trademarks or registered trademarks of American Express Global Network Services. JCB®, J/Smart®, and J/Speedy® are trademarks or registered trademarks of JCB Co., Ltd. Discover®, DFS Financial Services, D-PAS, and ZIP are trademarks or registered trademarks of DFS Financial Services LLC.  EMV™ is a registered wordmark of EMVCo, LLC. UnionPay, China UnionPay, CUP, CUPIC, UPcash and QuickPass (and their Chinese equivalents) are trademarks or registered trademarks of China UnionPay Co. Ltd. EMV™ is a registered wordmark of EMVCo, LLC. Any use of these words or other trademarked words within this document carries the implication of the trademark’s registration status, whether the "®" or "™" symbol is present or not.