Versions Compared

Old Version 2

changes.mady.by.user Olivier Chauvineau

Saved on

compared with

New Version Current

changes.mady.by.user Alexandre PERRIER

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

F

Table of Contents

Note

This page is subject to modifications on a weekly basis due to specs, test plans, and tools updates

Table of Contents

Agnos Framework Features Implementations

AGF 3.2.x vs AGF 3.3.x

Main differences are on HAL. Since 3.3.x, Agnos introduces the DEVICE layer that resides below the GPI.

AGF 3.3.x vs AGF 3.5.x

AGF 3.5.x introduces new architectural concepts such as:

  • API serialization

  • Exit conditions

  • GPI callbacks

Info

All versions presented below have been certified at a given time for a given Agnos Framework-Tool-Test Plan combination

Components

AGF 3.6.x

AGF 3.5.x

AGF 3.4.x

AGF 3.3.x

AGF 3.2.x

Last Update

Development Version

Limited Version

Maintained Version

Maintained Version

DEVICE

N/A

version 1.4.3

N/A

GPI

N/A

version 3.3.17

version 3.2.48

AgnosDB

version 3.5.12

N/A

version 3.3.12

version 3.2.30

Agnos

version vxxCAAgnos35_22

N/A

version vxxCAAgnos33_22

version vxxCAAgnos32_17

AgnosMW

version 3.5.22

N/A

version 3.3.20

version 3.2.49

AgnosEP

Implementation 3.6.8

Implementation 3.5.34

N/A

Implementation 3.3.34

version 3.2.62

Mastercard

specifications 3.1.3/3.1.4 (mode 1 and 4) / TEI

implementation 1.0.6

N/A

N/A

specifications 3.1.3/3.1.4 (mode 1 and 4)

implementation 1.0.6

Visa

specifications

VCPS 2.2c

VCTKS 1.0

VRTPKS 1.1

implementation 1.0.24

specifications 2.1.3c / 2.2b / 2.2c / VCTKS / VRTPKS

implementation 1.5.14

N/A

N/A

specifications 2.1.3c / 2.2b / VCTKS

implementation 1.5.15

American Express

specifications 4.0.3

implementation 1.0.25

specifications 4.1.0

implementation 1.0.25

specifications 4.0.2 / 4.0.3

implementation 1.0.14

N/A

N/A

specifications 4.0.2 / 4.0.3

implementation 1.0.14

JCB

specifications 1.5c

implementation 1.0.17

specifications 1.6a

implementation 1.0.14

specifications 1.5c

implementation 1.0.17

N/A

N/A

specifications 1.4c

implementation 1.3.7

Discover

specifications ZIP / DPAS 1.0

implementation 1.3.51

N/A

N/A

specifications ZIP / DPAS 1.0

implementation 1.3.52

CUP

specifications 1.0.2

implementation 1.3.14

N/A

N/A

specifications 1.0.2

implementation 1.3.14

C-PACE

In Progress

No

No

Interac

specifications 1.5d

implementation 1.3.28

N/A

N/A

specifications 1.5d

implementation 1.3.28

eftpos

N/A

N/A

specifications 18.04

implementation 1.0.4

No

No

PURE

specifications 2.1.8

implementation 1.0.14

N/A

N/A

specifications 2.1.8

implementation 1.0.14

No

No

Wise

N/A

N/A

specifications 2.0

implementation 1.3.4

No

No

Bancomat

N/A

specifications 2.2.0

implementation 1.0.18

RuPay

N/A

specifications 2.0

implementation 1.3

Girocard

In Progress

No

EMVCo Contact Test Application

specifications EMVCo 4.3j

implementation 3.5.1

N/A

specifications EMVCo 4.3j

implementation 3.3.3

specifications EMVCo 4.3i

implementation 3.2.23

C-POC Ready

Yes

No

No

No

OLA for Payment Application

Yes (Arkos/Atheos Compliant - Nexo Ready)

No

Yes (Arkos/Atheos Compliant)

AgnosSP

Yes

No

No

No

GPI Testing System (GTS)

Yes

No

No

No

ACE (embedded edition)

No

versoin 3.3.28

Torn Transactions

Torn is an EMV feature specified by some payment networks in the context of contactless card processing. All the payment networks specifications for torn transactions are meant to spare card’s internal counter. So, the feature is - globally - pretty similar across the board. But MV details are different making the feature specific from an implementation stand point.

Mastercard

JCB

CUP

PURE

Rupay

Agnos Availability

Supported

Supported

Not Supported

Supported

Not Supported

Functional Description

  • After a torn, a brand new transaction is started. If the new card processing sequence is using one of the cards that has been previously torn (in the limit of torn depth and max lifetime) then a Recover AC command is sent instead of a Generate AC

  • After a torn, a brand new transaction is started. If the new card processing sequence is using the card that has been previously torn then an Echo command is sent so a subsequent Generate AC will be spared

  • After a torn, the transaction is resumed from where it was torn. If the card processing is using the card that has been torn (FCI comparison subsequent to a Select) then

a

  • an Echo command is sent to resume the card processing from where it was torn

Configuration

  • 0xDF1D, torn depth (up to 5)

  • 0xDF1C, max lifetime (up to 7200 seconds)

  • 0xDF1D, torn depth (wired to 1)

  • 0xDF1C, max lifetime

  • C7 B3b6, Terminal Transaction Processing Information

Trigger

  • Generate AC not completed

  • Generate AC not completed

  • Generate AC #1

and

  • or Generate AC #2 not completed

Storage Mechanism

  • When a torn occurs, add a torn record:

    • 9F02

    • 9F03

    • 5A (primary key for recovery)

    • 5F34 (primary key for recovery)

    • DF04

    • 9F34

    • 9F7D

    • DF28

    • 9F1E

    • 9F33

    • 9F1A

    • 9F35

    • 95

    • 9F53

    • 5F2A

    • 9A

    • 9F21

    • 9C

    • DF51

    • DF53

    • DF54

    • DF55

    • DF56

    • DF41

  • Additional data are used for internal recovery management

  • When a torn occurs, add a torn record:

    • 57 (primary key for recovery)

    • if CDA supported:

      • 9F38 data

      • 8C data

      • 9F37

  • When a torn occurs, add a torn record:

    • 9F37

    • 9F27

    • 9F34

    • 9F10

  • For recovery, the FCI subsequent to a Select command is used to detect whether the card has been torn

Restart

  • END APPLICATION

  • Start B

  • PRESENT CARD AGAIN

  • END APPLICATION

  • Start B

  • PRESENT CARD AGAIN

  • TRY AGAIN

  • Start B

  • PRESENT CARD AGAIN

Check Point

  • The kernel is re-activated to perform a brand new transaction

  • Right before Generate AC, the kernel checks whether there was a torn situation (among

several torn cases)

  • the last card processing sequences) in order to send - or not - a Recover AC command

  • The kernel is re-activated to perform a brand new transaction

  • After Final Select, the kernel checks whether there is a torn situation (during the last card processing sequence) in order to send - or not - an Echo command

  • The kernel is re-activated and is set to jump to one of the torn states (when the torn occurred):

    • Recovery from Generate AC #1

    • Recovery from Generate AC #2

  • From one of this state, the kernel checks whether there is a torn situation (during the last card processing sequence) in order to send - or not - an Echo command

Too Old Verification

  • Yes

  • No

  • No

Recovery

Mechanism

Timing

  • Recover AC performed instead of the Generate AC

  • Echo performed at a specific state, occurring between Final Select and GPO

  • Echo performed right after the occurrence of the Generate AC (once the start B was processed by the entry point) and the Select (to get the FCI)

Recovery APDU

  • 80 D0 00 00 Lc data where:

    • Lc is DRDOL length followed by corresponding DDOL data

  • 80 DF 00 00 00

  • 80 DF xx 00

xx

  • Lc data where:

    • xx corresponds to the Generate AC number (1 or 2)

Recovery Principle

  • From Echo command, fetch tags to be used at Generate AC time

After Recovery

  • Card processing is resumed to reach the next step: GPO

When recovery failsIn torn mode if

    • Lc is:

      • 4 if xx = 1 (and data = 9F37 value)

      • 8 if xx = 8 (and data = 91 value)

When A Recovery Command Fails

  • If the recovery fails then a Generate AC will be sent to the card like during the normal path of execution

  • If communication error:

    • END APPLICATION

    • Start B

    • A brand new transaction will start

  • Else

The transaction is resumed:

    • If no status word error

Like

    • then normal torn path of execution

    • Else like a regular transaction is any other error

  • Generate AC #1 recovery:

    • If communication error:

      • TRY AGAIN

      • Start B

      • A brand new transaction will start

    • Else if cancellation:

      • END APPLICATION

      • STOP

    • Else if status word error:

      • SELECT NEXT RETRY

      • Start C

      • A brand new transaction will start

    • Else

(normal path):

    • :

      • Normal torn path of execution

  • Generate AC #2 recovery:

    • if communication error:

      • TRY AGAIN

      • Start A

      • A brand new transaction will start

    • Else

(normal path)

  • Attempt to perform EMV completion

Indicators

AgnosTVR B20b1

    • :

      • Normal torn path of execution

Indicators

  • N/A

  • AgnosTVR B20b5 (torn transaction)

  • AgnosTVR B20b6 (torn activated)

  • AgnosTVR B20b1 (torn recovery initiated)

  • AgnosTVR B20b8 (not torn card)

  • AgnosTVR B20b2 (torn recovery error)

  • AgnosTVR B20b4 (torn recovery - missing 9F52)

  • N/A

Card Processing State

  • N/A.

In

  • A Recover AC is sent instead of a Generate AC in the same state as a regular card processing,

a Recover AC is sent instead of a Generate AC)

  • psStateTornRecovery (AgnoTVR B18 =

0x02

  • 2)

  • psStateRecoverFRomGenAC1 (AgnoTVR B18 = 20)

  • psStateRecoverFRomGenAC2 (AgnoTVR B18 = 21)

Notes

  • N/A

  • If a torn recovery is initiated, Read Record process is interrupted

as soon as a card is detected as being previously torn

  • if the card that is processed is not the one that was previously torn. In that case, the transaction ends (outcome is END APPLICATION)

  • The ability to support a torn transaction

also

  • depends on the

card

  • card’s FCI (presence of PURE Echo card id, tag 9F75, in FCI/BF0C). If it is not the case then the transaction ends (outcome is END APPLICATION with error L3 = STOP )

Data Exchange

To be competed…

Transit

Supported

Option Name

Mastercard

Yes

Integrated Data Storage

Visa

Yes

VCTKS

American Express

N/A

N/A

JCB

Yes

Transit

Discover

N/A

N/A

CUP

Yes

Transit

C-PACE

N/A

N/A

Interac

Yes

Transit

eftpos

N/A

N/A

PURE

N/A

N/A

Wise

N/A

N/A

Bancomat

N/A

N/A

RuPay

Depends on integration context

N/A

C-POC Ready

All kernels' versions are identicial to the ones used on conventional acceptance systems.

Brands

Supported

COTS LoA/LoC

Option Name

Mastercard

Yes

Yes

Standard Test Plan

No Magstripe

No IDS Torn

Visa

Yes

Yes

VRTPKS Test Plan

Online only

Signature

Online PIN

No DRL

No Cash

No Cashback

No Printer

American Express

Yes

Yes

Standard Test Plan

Onlline Only

Unable to Go Online

JCB

N/A*

No

N/A*

Discover

N/A*

No

N/A*

CUP

N/A*

No

N/A*

Pure

N/A*

No

N/A*

* As of , there is no clear guidance on a specific Tap On Phone / Tap To Phone ICS. Standard ICS may be used with limited options.