KR102113938B1 - 국부적 거래승인을 위한 네트웍 브리지 - Google Patents

국부적 거래승인을 위한 네트웍 브리지 Download PDF

Info

Publication number
KR102113938B1
KR102113938B1 KR1020187017162A KR20187017162A KR102113938B1 KR 102113938 B1 KR102113938 B1 KR 102113938B1 KR 1020187017162 A KR1020187017162 A KR 1020187017162A KR 20187017162 A KR20187017162 A KR 20187017162A KR 102113938 B1 KR102113938 B1 KR 102113938B1
Authority
KR
South Korea
Prior art keywords
value storage
transaction
storage card
bridge
processor
Prior art date
Application number
KR1020187017162A
Other languages
English (en)
Other versions
KR20180090827A (ko
Inventor
앤드류 오로크
데이비드 빌리어
Original Assignee
이투인터액티브 인코포레이티드
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 이투인터액티브 인코포레이티드 filed Critical 이투인터액티브 인코포레이티드
Publication of KR20180090827A publication Critical patent/KR20180090827A/ko
Application granted granted Critical
Publication of KR102113938B1 publication Critical patent/KR102113938B1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/20—Point-of-sale [POS] network systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/20—Point-of-sale [POS] network systems
    • G06Q20/204—Point-of-sale [POS] network systems comprising interface for record bearing medium or carrier for electronic funds transfer or payment credit
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/342—Cards defining paid or billed services or quantities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3674—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes involving authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/403—Solvency checks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/409—Device specific authentication in transaction processing

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Finance (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Cash Registers Or Receiving Machines (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

본 발명은 소매상 POS(Point-Of-Sale)/호스트에 근접해있고, POS/호스트 및 가치저장카드 프로세서와 선택적으로 통신하는, 국부적 가치저장카드 거래 처리장치에 관한 것이다. 이 장치는 POS나 호스트와의 선택적 통신을 가능케하는 POS/호스트 인터페이스; 가치저장카드 프로세서와의 선택적 통신을 가능케하는 가치저장카드 프로세서 인터페이스; 및 소정의 가치저장카드 거래요청들에 대한 선택적 결정을 하는 프로세싱 모듈을 포함한다.

Description

국부적 거래승인을 위한 네트웍 브리지
본 발명은 국부적 거래승인을 위한 네트웍 브리지에 관한 것이다.
활성화, 비활성화, 상환, 리로드, 리프레시와 같은 가치저장카드의 거래에는 원격 프로세서나 서버와통신하여 이 거래의 승인을 받거나 거래를 수행하기 위해 일반적으로 소매상의 POS(point of sale) 단말기, 시스템 또는 호스트가 필요하다. 그러나, 어떤 환경에서는 원격 프로세서와의 통신이 (예컨대 정전이나 망폭주로 인해) 불가능하거나 (피트타임이나 망과부하로 인해) 제때 이루어지지 않을 수 있다.
따라서, 가치저장카드 거래를 국부적으로 승인 및/또는 수행하는 시스템과 방법이 필요하다. 또, 원격 프로세서와 관련 데이터 저장장치들을 새로운 거래정보로 업데이트하도록 이 프로세서와 통신할 수 있는 시스템과 방법도 필요하다. 이런 시스템과 방법은 거래와 거래요청들을 더 QK르게 처리할 수 있다.
아주 특정한 환경에서 어느정도 국부적 승인을 할 수 있는 가치저장카드 시스템들은 많지만, 이런 시스템들은 (i) 타임아웃시 소정의 거래 타입들을 계속 거절하면서 지정된 거래 타입들에 대해 대리승인 기능을 추가하고; (ii) 보고된 대로의 소정의 "소프트 거절(soft declines)"에 대해 대리 기능을 제공하며; (iii) SAF(store-and-forward) 거래에서 비롯되는 아웃바운드 요청들에 대한 STAN(unique system trace audit number) 제공과 같은 특정 조건들을 구현하고; 및/또는 (iv) 운용관리급 감독을 위하 SAF 콘텐트에 대한 가시성을 획득하는 능력을 갖출 수 없다. "소프트 거절"은 가치저장카드 프로세서는 거래를 거절하되 발행자나 프로세서(즉 상품 및/또는 거래에 대한 실제 인가자)는 이 거래를 거절하지 않을 수 있는 거절을 말한다.
본 발명은 이런 목표를 달성할 수 있는 시스템과 방법을 제공하는 것을 목적으로 한다.
발명의 요약
본 발명은 소매상 POS(Point-Of-Sale)/호스트에 근접해있고, POS/호스트 및 가치저장카드 프로세서와 선택적으로 통신하는, 국부적 가치저장카드 거래 처리장치에 있어서: POS나 호스트와의 선택적 통신을 가능케하는 POS/호스트 인터페이스; 가치저장카드 프로세서와의 선택적 통신을 가능케하는 가치저장카드 프로세서 인터페이스; 및 소정의 가치저장카드 거래요청들에 대한 선택적 결정을 하는 프로세싱 모듈을 포함하는 국부적 가치저장카드 거래 처리장치를 제공한다.
본 발명은 또한 소매상 POS(Point-Of-Sale)/호스트, POS/호스트와 함께 국부적으로 배치된 브리지 프로세서, 및 가치저장카드 프로세서 사이에서 이루어지는, 국부적 가치저장카드 거래 승인방법을 제공한다. 이 방법은 브리지 프로세서가 거래요청을 받는 단계; 거래요청이 가치저장카드에 보내졌는지 또는 국부적으로 결정되었는지 여부를 브리지 프로세서가 결정하는 단계; 거래요청이 가치저장카드 프로세서에 보내졌다고 결정되면, 이런 거래요청을 브리지로부터 가치저장카드 프로세서에 보내고, 가치저장카드 프로세서로부터, 또는 가치저장카드 프로세서와의 통신으로부터 소정의 응답을 받았을 때 가치저장카드 프로세서의 응답을 브리지 프로세서가 덮어쓰거나 국부적으로 거래요청을 결정하는 단계; 거래요청이 가치저장카드 프로세서에 보내지지 않았다고 결정되면, 거래요청을 브리지 프로세서가 국부적으로 결정하는 단계; 및 거래요청 응답을 브리지가 POS/호스트에 돌려보내는 단계;를 포함한다.
본 발명은 또한 소매상 POS/호스트에 근접해있고, POS/호스트 및 가치저장카드 프로세서와 선택적으로 통신하는, 국부적 가치저장카드 거래 처리장치도 제공하는데, 이 장치는 아래와 같은 기능을 할 수 있다: 거래요청을 받고; 거래요청이 가치저장카드에 보내졌는지 또는 국부적으로 결정되었는지 여부를 결정하며; 거래요청이 가치저장카드 프로세서에 보내졌다고 결정되면, 이런 거래요청을 가치저장카드 프로세서에 보내고, 가치저장카드 프로세서의 응답을 국부적으로 덮어쓰거나 거래요청을 국부적으로 결정하며; 거래요청이 가치저장카드 프로세서에 보내지지 않았다고 결정되면, 거래요청을 국부적으로 결정하고; 거래요청 응답을 POS/호스트에 돌려보내며; 국부적 덮어쓰기나 국부적 결정 후, 이런 덮어쓰기나 결정에 관한 정보를 저장하고, 통신이 재설정되면 이런 정보를 가치저장카드 프로세서에 보낼 수 있다.
도 1은 본 발명에 따라 처리기능이 제한된 SAF 모델의 일례를 보여주는 도면;
도 2는 본 발명에 따라 모든 처리기능을 갖춘 SAF 모델의 일례를 보여주는 도면;
도 3은 본 발명에 따라 각종 거래 흐름은 물론 다른 거래 당사자와 관련된 브리지의 역할을 보여주는 도면;
도 4는 SAF 임팩트 없이 대리승인을 하는 소프트 거절을 취급하는 과정을 보여주는 도면;
도 5는 대리승인을 하는 소프트 거절과 SAF 하드 거절을 취급하는 과정을 보여주는 도면;
도 6은 거래가 최대 재시도 횟수를 히트할 때 대리승인을 하는 소프트 거절을 취급하는 과정을 보여주는 도면;
도 7은 대리승인을 하고 호스트 타임아웃에 대한 과정을 보여주는 도면;
도 8은 대리승인을 하고 호스트 타임아웃을 위한 프로세서를 보여주는 도면;
도 9는 서스펜드 모드의 일례를 보여주는 도면;
도 10은 발기인 기반 무효와 거절 과정을 보여주는 도면;
도 11은 펜딩 SAF 거래 과정을 보여주는 도면;
도 12는 SAF내 보완 아이템의 과정을 보여주는 도면;
도 13은 UPC(universal product code)가 예상범위내에 없는 상품의 취급과정을 보여주는 도면;
도 14는 SAF 시스템에 대해 능동적이 아닌 UPC를 갖는 상품의 취급과정을 보여주는 도면.
도 1의 구성에서, 예컨대 카치저장카드 프로세서의 응답을 기다리면서 금융거래가 소매상의 호스트에서 타임아웃되면 , TOR(timeout reversal)이 생겨 SAF 시스템에 제공된다. 그렇지 않으면 호스트가 다른 거래에 대해 가치저장카드 프로세서와 직접 통신한다. 이어서, 소매상(110)이 가치저장카드 프로세서(120)와 직접 통신하고, 프로세서는 서비스 공급자(130)와 통신한다.
서비스 제공자(130)가 가치저장카드를 실제로 발급하거나 상환하는 당사자일 수 있다. 가치저장카드 프로세서(120)가 다수의 가치저장카드들에 관한 서비스들을 제공하는 중간 당사자일 수도 있다. 소매상(110)은 일반 소매상이거나 POS를 갖춘 상인으로서, 예컨대 다수의 가치저장카드들을 판매용으로 제시하는 왈그린(Walgreen)일 수 있다. 가치저장카드 프로세서(120)는 왈그린에서 제공한 다수의 가치저장카드들에 관한 서비스와 활성화를 제시하는 Interactive Communications International사나 InComm일 수 있다. 서비스 제공자(130)가 카드발급자를 위한 카드거래를 취급하는 당사자(예; Stored Value Solutions)로서 Bed Bath & Beyond 기프트카드를 위한 카드거래를 취급할 수도 있다.
대부분의 거래 동안, 호스트는 거래요청(141)을 가치저장카드 프로세서(120)에 전달하고 프로세서로부터 응답(142)을 받는 창구역할만 할 수도 있다. 그러나, 환경에 따라서는, 호스트(110)와 가치저장카드 프로세서(120) 사이의 통신에 타임아웃(143)이 있을 수도 있다. 이 경우, 호스트(110)가 TOR(144)을 생성해 SAF 큐(145)에 제공할 수 있다. SAF 시스템이 이어서 가치저장카드 프로세서(120)와 통신하여 부적절하게나 불완전하게 이루어진 모든 거래를 취고할 수 있다. 도 1에서 보듯이, 이런 SAF 시스템은 아주 제한된 기능을 갖는다.
본 발명에 의하면, 브리지가 다른 무엇보다도 아래 중의 하나 이상을 위해 제공된다: (i) (POS 레벨이 아니거나 추가하여) 호스트 레벨에서의 대리승인; (ii) 확인된 거래 종류만 허용(예; 대리 활성화만 허용); (iii) 확인된 제품이나 제품거래 타입 조합 허용; (iv) "소프트 거절" 및/또는 타임아웃 동안 브리지와 SAF 시스템 사이의 통신 자동허용; 및 (v) 판매관계자나 기술자에게 브리지/SAF 활동 결과 제공(예; POS 디스플레이에 디스플레이하거나 영수증에 인쇄).
어떤 거래는 로컬에서 결정되고 다른 거래는 가치저장카드 프로세서의 응답이 필요할 수 있어 더 빠르고 효율적인 처리를 위해 이런 기능이 제공된다. 또, 통신이 없거나 에러가 있을 때, 이런 시스템과 방법은 거래가 누적되는 것을 방지하고 비효율적인 프로세서 과부하를 방지하여 시스템을 좀더 효율적이고 빠르게 운용할 수 있다.
본 발명은 POS 시스템/호스트와 가치저장카드 프로세서 사이의 브리지에 관한 것이다. 브리지는 한가지 이상의 기능을 갖는데, 예를 들어 프로세서와의 통신이 적시에 유효하면 브리지는 프로세서와의 통신 창구이고 거래요청의 라우팅을 보조할 수 있다. 프로세서와의 통신이 불가능하거나 적시에 일어나지 않으면, 브리지가 대리 프로세서로 기능하여 소정의 거래를 한다. 프로세서와의 적절한 통신이 재개되면 브리지가 프로세서를 업데이트고, 브리지가 대리로 인증하거나 수행한 거래와 관련된 업데이트 정보와 하께 모든 관련 데이터가 저장된다.
브리지가 POS/호스트와 가치저장카드 프로세서의 중간에 위치할 수 있는바, 예를 들면 창구 거래를 받아 보낼 위치로 POS/호스트 장소에 물리적으로 위치하거나, 필요한 대리 거래를 위한 연결성을 갖는 곳에 위치할 수도 있다.
POS/호스트 장소에 브리지가 위치하면 추가 장점을 갖는다. 브리지의 목적이 소정의 가치저장카드 거래에 대한 연속적인 서비스를 제공하는데 있으므로, POS/호스트 장소에 위치한 브리지는 POS/호스트와 같은 환경에 있을 수 있다. 즉, 브리지가 POS/호스트에서 멀리 있으면 그 장소에 정전이나 네트웍 문제가 있을 수 있지만, POS/호스트 장소는 정상으로 동작할 수 있다. 브리지의 목표중 하나가 POS/호스트를 연속으로 지원하는데 있으므로, POS/호스트와 브리지를 같이 위치시키면 환경적인 인자들이 같거나 비슷해지고 대리 인증이나 거내를 진행하는데 제한된 네트웍통신이 필요할 수 있다.
본 발명의 시스템과 방법들은 SSD(solid state drive)에 이용할 수 있다. SSD는 예컨대 Intel Xeon ES-2609 프로세서를 이용하는 HP PorLiant DL380P G8 2U를 포함하고, 하나 이상의 로드밸런서 및/EH는 멀티플렉서를 통해 POS/호스트와 직접 통신할 수 있다.
브리지는 소매상에서의 대리거래와 창구거래를 위한 SAF(store-and-forward) 기능을 구현할 수 있다. 본 발명의 브리지는 (i) 타임아웃시 소정의 거래를 계속 취소하면서도 지정된 거래 타입에 대해서는 대리 승인을 하고; (ii) 보고된대로의 "소프트 거절"을 위한 대리 기능들을 제시하며; (iii) SAF 거래에서 기인하는 아웃바운드 요청에 대한 고유 STAM을 제공하는 것과 같은 특정 조건을 구현하고; 및/또는 (iv) 연산적이면서 관리적 레벨의 실수를 위해 SAF 콘텐트에 대한 가시성을 획득하는 기능을 제공할 수 있다.
브리지가 완전한 기능을 제공하려면 소매상 시스템의 변화가 필요하다고 본다. 예를 들어, 가치저장카드 거래를 프로세서에 직접 하기보다 브리지에 보내도록 거래 라우팅의 세팅을 소매상이 바꿔야할 수 있다. 마찬가지로, 대리 승인과 대리 거절에 관련된 새로운 응답코드를 지원하도록 소매상이 시스템을 바꿀 수도 있다. 이런 응답코드는 SAF 이벤트들과 브리지 결정하기를 추적하고 연관시키는데 유용할 수 있다. 또, 소매상들이 환경에 따라서는 고객들에게 추가 POS 안내를 할 수도 있다. 예컨대, 구매한 상품을 대리 승인할 경우, 이 상품이 24시간내에 활성화될 것이라는 정보를 고객이 받을 수 있다. 이 정보를 (판매담당이 고객에게) 말로 알려주거나 영수증에 인쇄될 수 있다.
도 2는 본 발명에 따라 브리지를 활용한 SAF 모델(20)을 보여준다. 이 모델(20)은 POS(211)나 호스트(212)를 갖춘 고객(210) 사이에 행해지는 가양한 거래들을 보여준다. "고객"이란 가치저장카드 프로세서의 고객인 상인이나 소매상을 의미하기도 한다. 예컨대 가치저장카드나 판매용 기프트카드를 제공하는 소매상이 "고객"일 수도 있다. 호스트(212)를 통한 통신이 일반적이지만 브리지(220)와 직접 통신하는 POS(211)와도 비슷한 거래를 할 수 있다고 본다. 고객(210)이 브리지(220)에 통신을 보내면, 브리지가 거래를 하거나 가치저장카드 프로세서(230)에 거래요청을 보낼 수 있다. 가치저장카드 프로세서(230)는 거래를 위해 서비스 제공자(240)와 통신한다.
도 2는 고객(210), 브리지(220), 가치저장카드 프로세서(230) 및 서비스 제공자(240)를 통해 일어나는 여러가지 거래 종류를 보여준다. 250의 차구 거래에서는 POS에서 시작된 거래가 호스트(212)와 브리지(220)를 통해 프로세서(230)로 보내진다. 가치저장카드 프로세서는 서비스 제공자(240)와 통신하는 것이 보통이지만, 이 프로세서가 서비스 제공자일 수도, 또는 추가 통신 없이 거래를 하도록 승인받을 수도 있다. 거래 응답은 브리지(220)와 호스트(212)를 통해 POS(211)로 되돌아간다.
251에, 호스트가 타임아웃되는 환경에 대한 거래 흐름이 표시되었지만(즉, 가치저장카드 프로세서(230)와의 통신이 적시에 유효하지 못함), 특정 상품종류(즉, 소정의 가치저장카드)는 "retry" 리스트에 없다. 이런 환경에서는 POS(211)에서 거래가 시작되어 호스트(212)로 보내질 수 있지만, 가치저장카드 프로세서(230)에는 그렇지 않을 수 있다. 이 상품의 거래가 브리지(220)에 의해 허용되지 않으면, 252에서 TOR(timeout reversal)이 발부되었다가, 가치저장카드 프로세서(230)와의 추후의 통신을 위해 SAF 큐(260)에 저장될 수 있다.
253에, 호스트가 타임아웃되는 환경에 대한 거래 흐름이 표시되었지만, 특정 상품종류가 "retry" 리스트에 있다. 이 거래는 POS(211)에서 시작해 호스트(212)로는 보내지지만, 프로세서(230)는 아니다. 그러나, 상품 종류가 "retry" 리스트에 있기 때문에, 브리지(220)가 254에서 거래의 대리 승인을 하고, 이런 대리승인은 프로세서(230)와의 추후 통신을 위해 SAF 큐(260)에 저장된다.
255에, "retry" 리스트에 있는 상품의 소프트 거절을 위한 거래흐름이 표시되었다. 마찬가지로, 이 거래는 POS(211)에서 시작해 호스트(212)로 보내지고, 브리지(220)가 대리 승인(256)을 하며 SAF 큐(260)를 업데이트한다.
257에, 로컬 브리지 행위를 이용해 승인될 거래 흐름이 표시되었는데, 이 거래는 POS(211)에서 시작해 호스트(212)로 보내지고 브리지(220)에 의해 인증, 승인 또는 수행된다. 마찬가지로, 브리지(220)는 모든 대리승인이나 거절에 관한 정보를 SAF 큐(260)에 제공하여 가치저장카드 프로세서(230)에 업데이트를 제공한다.
끝으로, 259에서 SAF 시스템이 브리지(220)에 의해 이루어지거나 거절된 거래의 리스트나 큐를 제공하여 프로세서(230)를 업데이트한다.
고객(210)이 이런 SAF 시스템을 브리지로 적절히 활용하려면, 시스템을 바꾸는 것이 좋을 것이다. 이런 변화로는 (i) 결정을 할 때 현재의 SAF 큐 콘텐트를 유효화하고; (ii) "하드(hard)" 거절과 "소프트" 거절을 구분하며; 및/또는 (iii) 각각의 SAF 요청 시도시 필드를 변화시키는 기능들을 제공하는 것이 있지만, 이에 한정되지도 않는다.
구체적으로, 결정을 할 때 현재의 SAF 큐 콘텐트를 유효화하기 위해, SAF 큐의 현재의 콘텐트로 SAF 결정을 안내할 수 있다. 예컨대, 같은 가치저장카드에 대한 활성화 요청이 SAF 큐에 이미 존재하는 동안 활성화 요청이나 리로드 요청을 받으면, 후속 거래가 국부적으로 거부되어야 한다.
"소프트" 거절과 "하드" 거절의 구분에 있어서, "소프트" 거절은 브리지가 할 수 있는 대리거래 후보이지만 "하드" 거절은 아닐 수 있다. 각각의 SAF 요청 시도에서의 필드를 바꿔, 같은 STAN(system trace audit number)의 반복적이거나 복제적인 사용을 금할 수 있다. 같은 STAN을 사용하면 가치저장카드 프로세서가 전과 같은 반응을 바동으로 반복하도록 한다. 따라서, 각각의 거래 요청에 대한, 특히 소프트 거절의 경우의 STAN의 변경이 추천할만 하다.
호스트 통합
브리지의 거래역량을 호스트에 통합하면 브리지 자체는 불필요할 수 있지만, 이런 통합을 방해하거나 지연할 수 있는 인자도 많기 때문에, 브리지를 사용하면 고객의 호스트에 대한 고가의 적시의 변형 없이도 국부적인 대리 거래 역량을 편리하게 구현할 수 있다.
환경설정
호스트가 브리지와 통신하도록 하려면, 여러개의 설정파일들이 필요할 수 있다. 예컨대, 브리지가 인가자에 연결하는 방법과 브리지가 응답이나 응답부족을 취급해야하는 방법을 'QueryHost' 거래 participant가 규정하고 제어할 수 있다. 'QueryHost' participant는 (실시간 요청을 취급하는) 메인 거래매니저와 (환경설정 결절의 결과로 SAF 큐에 있는 아이템들의 후속 언로딩을 취급하는) SAF 거래매니저 달다에 의해 호출될 수 있다.
아래 실시예와 여기 소개된 모든 코딩이나 파일들에서, 특정 배열, 알고리즘 및/또는 정보의 제시는 예를 든 것일 뿐이다. 동일하거나 비슷한 결과를 달성하는 방식은 많다. 또, 예로 든 코딩은 가치저장카드 프로세서로서 InComm을 예로 든다. 제시된 코딩은 여러 방법으로 바뀔 수 있다.
participant 'QueryHost'는 아래와 같다(아래 제시된 값들은 초기값들의 일례이고 최종 제품 세팅을 보증하려는 것은 아니다):
Figure 112018066593417-pct00001
QueryInCommHost에서 규정된 속성에 대해 설명한다.
mux
엔드포인트에 대한 브리지의 채널연결을 제어하는 멀티플렉서의 명칭. 엔드포이트에 대해 mux-pool이 구성되면, 그 명칭이 대신 리스트됨.이 값은 엔드포인트에 대한 브리지의 대응 먹스 성분(또는 먹스-풀 성분)에 포함된 이름과 일치한다. 예컨대, 22_incomm_mux_pool.xml의 첫번째 라인은:
Figure 112018066593417-pct00002
saf
관련 SAF 매니저의 명칭
이 값은 대응 SVCSAF=class SAF 성분에 포함된 명칭과 일치할 수 있다. 예를 들어, 20_incomm_saf.xml의 첫번째 라인은:<saf
Figure 112018066593417-pct00003
threshold
(외부 승인을 받기 전에) 내부적으로 거래를 거절할 수 있는 시간(ms). 예를 들어 리스트된 임계치가 3.5초이고, 타이머가 송신 허용 시점에서 3500ms보다 크면 브리지에서 내부적으로 거래가 거절되고 RC를 'D5'로 설정.
timeout
Query Host가 거래 응답을 하도록 원격 인가자에게 제공하는 시간(ms). 이 시간내에 응답이 없으면 거래는 타임아웃 요청으로 간주됨.
retry-response-codes
인가자로부터 받은 응답코드로 인해 브리지가 요청이 잘못 전달된 것으로 취급할 수 있다. 요청의 프로세싱 코드가 "retry" 코드로 정해지면, 요청은 SAF-able로 간주되고 이 물품이 SAF 테이블에 기록됨.
retry-transaction-codes
실시간 요청의 타임아웃에서, 또는 'retry-response-codes'에 포함된 값과 같은 RC를 받는 실시간 요청에서 "SAF-able"인 프로세싱 코드(즉, 'PC', ISO8583 field 3) 값 리스트. 예컨대, 이 필드가 value=189090으로 정의되면, 위의 (a)나 (b)의 상황이 이런 거래코드에 맞닥드렸는지 재시도를 요청하는 행을 브리지가 'safMeta'와 'safdata' 테이블들에 라이트할 수 있다.
그러나, 이 리스트에 포함되지 않은 거래코드에 대해, '타임아웃' 시나리오 (a)에서의 반전, 또는 'retry RC' 시나리오 (b)에서 RC의 소프트 거절을 (거래 유발자로 다시) 보내길 요청하는 행을 브리지가 SAF 테이블에 라이트할 수 있다.
어떤 브리지 설비에서 PC 189090내에 존재할 수 있는 아래 예외처리를 보면:
189090은 활성화를 나타내지만 유니버설 스와프 리로드("swipe reload")를 나타낼 수도 있다. 활성화가 SAF-able 거래이지만, swipe reload는 아닐 수 있다. 브리지가 활성화와 swipe reload를 구분토록 하는 다른 필드들이 189090에 없을 수 있다. 따라서, swipe reload 거래를 처리하는 각각의 브리지 고객에 대해, 고객과 가치저장카드 프로세서가 시그널링 방법을 결정할 수 있다.
189090이 retry-transaction-code로 규정된다 해도, 브리지는 이 리스트에 포함되지 않은 거래코드인 것처럼 swipe reload로 확인된 모든 요청을 처리할 수 있다.
suspend-manager
엔드포인트를 위한 브리지의 'suspend' 연산을 제어하는 시스템 요소의 명칭. 이 값은 엔드포인트를 위한 브리지의 해당 서스펜드 요소에 포함된 명창과 일치할 수 있다. 예컨대, 12_suspend_manager.xml이 라인 <suspend-manager class="com.ols.incomm.SuspendManager" logger-"Q2">를 포함할 수 있다.
saf -on-disconnect
엔드포인트까지의 모든 루트의 연결이 끊긴 "mux disconnect"로 알려진 상태이면 고객이 대리를 원하는지 여부를 나타내는 설정값.
'false'로 설정되면 모든 거래요청이 mux disconnect 동안 거절 코드 'D4'로 되돌아간다.
'true'로 설정되면 'retry-transaction-codes' 리스트에 있지 않은 아이템들의 거래요청이 mux disconnect 동안 거절 'D4'로 돌아가고; 'retry-transaction-codes' 리스트에 있는 아이템들에 대해서는 승인코드로 돌아가며, mux가 뒤에 재연결될 때 보내도록 아이템을 SAF에 둘 수 있다.
checkpoint
거래를 위한 q2.log 엔트리내의 거래 프로파일러에 나타나는 거래 participant 스텝을 위한 서술적 명칭. 이 특성은 각각의 participant가 특정 거래를 담당하는 시간(ms)을 표시한다.
SAF 매니저 정의
브리지에 탑재된 엔드포인트가 확정전개된 SAF 매니저 요소를 요할 수 있다. 이런 SAF 매니저가 담당하는 것은 (i) SAF 큐 언로딩, (ii) SAF 복제 리트라이, (iii) SAF 동기화이다. 구체적으로, SAF 매니저는 지정된 엔드포인트로 보내질 SAF 엔트리들을 확인한다. 아이템을 보낼 수 있으면, SAF 매니저가 SAF Transaction Manager에 의한 핸들링을 위해 큐(SAF.TXN)에 가장 관련있는 엔트리를 둘 수 있다.
SAF 복제는 언로딩 프로세스의 일부로서 피어노드로 실행될 수 있다. 복자가 실패하면(예; 피어로의 요청이 타임아웃), SAF 매니저가 Retry Transaction Manager에 의한 핸들링을 위해 큐(RETRY.TXN)의 리스트에 가장 관련있는 엔트리를 둘 수 있다.
피어가 다운된 것을 노드가 알면, 노드는 'SOLO' 모드에서 연산을 시작하고, 이 모드에서는 SAF 엔트리들을 양쪽 노드로 전달할 책임이 잇다. 이어서, 피어가 백업된 것을 노드가 알면, 대신해 취한 모든 행위들을 피어에 동기시켜야 한다. 동기화되면, SAF 매니저가 Sync Transaction Manager에 의한 핸들링을 위해 큐(SYNC.TXN)의 리스트에 가장 관련있는 엔트리들을 둘 수 있다
예컨대, 브리지 방식에 엔드포인트를 통합하기 위한 SAF 매니저 정의는:
Figure 112018066593417-pct00004
SAF 매니저에 규정된 속성에 대해 설명한다:
endpoint
외부 거래 인가자의 명칭. 이 값은 엔드포인트를 위한 해당 메인 거래 매니저내의 'StoreInSAF' participant에 비슷한 명칭의 속성으로 제공된 값과 일치할 수 있다. SAF 테이블이 하나의 외부 인가 인터페이스 이상의 엔트리들을 포함할 수 있기 때문에 이것이 존재한다.
echo- mgr
엔드포인트에 대한 브리지의 네트웍 레벨 'echo' 요청을 제어하는 시스템 요소의 명칭. ISO8583에서는 '0800' 시리즈 메시지이다.
이 값은 이 엔드포인트에 대한 브리지의 대응 echo 요소에 포함된 명칭과 일치할 수 있다. 예를 들어, 15_incomm_echo_mgr.xmldl 포함할 수 있는 라인은
Figure 112018066593417-pct00005
일 수 있다.
initial-delay
브리지 요소들이 메인 논리 루프를 시작하기 전에 서비스 개시(또는 요소 재배치)를 대기할 수 있는 시간(ms). 예컨대 '10000'(10초)의 값에서 브리지 어플이 SAF 연산이 시작하기 전에 완전히 편리하게 시작할 수 있다.
penalty-box-time
SAF에서 보내려고 한 이전 시도로 'retry' 출력이 되었을 경우 브리지가 SAF로부터 아이템을 보내려는 재시도 전에 대기하는 시간(ms).
이 값은 중요한 페이싱 메커니즘인데, 이는 실패 확률이 높은 신속반복적인 시도들에 의해 인가자가 겪는 문제들을 브리지가 악화시키지 않도록 하는데 도움이 되기 때문이다.
polling-delay
메인 프로세싱 루프의 결론 뒤 프로세싱을 재시작하기 전에 브리지가 대기하는 시간(ms). 아이템 리스트를 조사할 때 브리지가 보낼 수 있는 아이템이 없다고 결정하면 재조사 전에 이 시간을 대기하거나, 하나 이상의 보낼 아이템이 있다고 결정되면 리스트의 모든 아이템에 대해 몇몇 종류의 해결책을 성공적으로 처리한다. 이 경우, 브리지는 메인 프로세싱 루프를 끝내고 재조사 전에 이 시간을 기다릴 수 있다.
max-saf-space-queue-size
SAF 매니저가 엔드포인트로의 전달을 위해 SAF 큐("SAF.TXN")에 놓을 수 있는 최대 SAF 엔트리 수.
"inter-message-delay"와 마찬가지로, 이 속성은 브리지의 페이싱 메커니즘의 일부일 수 있다. 여기에 더 많은 수를 놓고 가능한 빨리 SAF 큐를 언로드하고자 할 수도 있다. 그러나, 인가자에게 과도한 부담을 주면 원래의 이슈를 악화시킬 수 있다.
너무 보수적인 값인 '1'이 관심을 높일 수도 있다. 큐의 상단의 아이템이 아이템 고유의 이유로 인가자에 의해 서비스될 수 없으면, 다른 모든 계류중인 아이템들이 차단될 것이다.
'6'과 같은 보통의 세팅값이 균형을 이룰 수 있다.
max-retry-space-queue-size
피어 노드로의 전달을 위해 SAF 매니저가 리트라이 큐('RETRY.TXN')에 놓을 수 있는 최대 SAF 엔트리 수.
max-sync-space-queue-size
피어 노드로의 전달을 위해 SAF 매니저가 싱크 큐('SYNC.TXN')에 놓을 수 있는 최대 SAF 엔트리 수.
max- retransmissions
브리지가 SAF 큐로부터 특정 아이템을 언로드할 수 있는 최대 횟수. 브리지는 'safMeta" 테이블의 'attempts' 컬럼에서의 전송시도를 계산할 수 있다. 임계치에 이르면, 브리지가 같은 컬럼에서 요청을 'MAX'로 표시해 이 아이템을 미래 고려사항에서 없앨 수 있다.
expire-after
'safMeta.created'에 기록된 타임스탬프에서 측정한 시간(초)으로서, 이 시간이 지나면 브리지는 더이상 SAF 테이블로부터 특정 아이템을 보내지 않는다. 임계치에 도달하면 브리지는 요청을 상태 컬럼에 'EXP'로 표시해 이 아이템을 미래 고려사항에서 없앨 수 있다.
node
SAF 요청을 처리하는 서버의 노드 정의. SAF 엔트리가 SAF 매니저에 의해 처리될 때, 이 값이 'lastNode' 컬럼에 기록됨. 정상적인 연산에서, 각각의 노드는 자체 SAF 콘텐트의 언로드를 담당한다. 노드가 'SOLO' 모드에 있으면, 이 노드는 양쪽 노드의 SAF 콘텐트의 언로드를 담당한다.
peer-node
2-서버 브리지 솔루션을 이루는 피어(즉, 다른) 서버의 노드 정의.
Echo Manager
본 발명의 에코 매니저는 네트웍 레벨의 메시지(예; 08xx 시리즈 메시지)를 브리지와 외부 인가자(예; 가치저장카드 프로세서) 사이에서 주고받을 수 있다. 에코매니저는 적어도 2가지 기능을 하는바: (i) 영구적으로 연결된 채널들을 저용량 시간에 활성상태로 유지할 수 있고(많은 원격 호스트들이 비활성 기간 뒤에 연결을 무너트림), 및/또는 (ii) 외부 인가자를 입증하고, 에코 요청에 대한 유효 응답을 받았을 때 브리지를 서스펜드 모드에서 빼내는 역할을 할 수 있다. 에코매니저 participant는 아래와 같이 정의될 수 있다:
Figure 112018066593417-pct00006
에코매니저의 속성에 대해 설명한다.
persistent-space
에코매니저의 현상태를 유지하는데 사용되는 메모리내 저장영역.
suspend-space
'서스펜드' 모드의 현상태를 유지하는데 사용되는 메모리내 저장영역.
mux
엔드포인트에 대한 브리지의 채널연결을 제어하는 멀티플렉서의 명칭. 이 값은 엔드포인트에 대한 브리지의 대응 먹스 성분에 포함된 명칭과 일치해야 함. 예컨대, 20_incumm_mux.xml의 첫번째 라인은 <mux class="org.jpos.q2.iso.QMUX"logger="Q2"name="incomm-echo-mgr"/>이다.
channel-ready
에코 요청에 응답하기 위해 QueryHost가 원격 인가자에게 주는 시간(ms). 시간내 응답이 없으면 거래는 타임아웃 요청으로 간주된다.
echo-interval
에코 요청 사이의 시간(ms)
max- timeouts
브리지가 어플을 '서스펜드' 모드에 두기 전에 허용할 수 있는 (네트웍급 요청이 아닌 고객의 거래요청에서의) 연속 타임아웃 횟수. 에코매니저는 브리지를 '서스펜드' 모드에서 다시 빼내는데 에코 요청에 대한 유효 응답의 수신을 이용할 수 있다.
node
서버의 노드 정의(즉, '1'이나 '2').
브리지 생성 응답코드
브리지가 거래를 중재해 어떤 액션을 하면, 고객의 어플에 응답코드("RC" - 필드 39)를 되돌릴 수 있다. 이런 'RC States'는 브리지의 결정에 관해 통찰력을 제공하고 취할 수 있는 다음 단계들에 관해 고객의 호스트에 안내를 하도록 설계된다.
브리지의 승인상태는 'Bx' 형태일 수 있다. 고객의 어플은 RC='Bx'(예; B1, B2 등)인 모든 응답을 승인된 거래로 취급할 수 있다.
아래 표는 B 상태 승인코드에 대한 설명이다.
코드 의미 SAF 취소
B0 거절시의 대리승인. 브리지가 'retry-response-codes' 리스트에 있는 인가자로부터 RC를 받았고; 프로세싱코드('PC')가 'retry-transaction-codes' 리스트에 있다. Y N
B1 타임아웃시의 대리승인. 브리지는 인가자의 응답대기를 타임아웃했고; PC가 'retry-transaction-codes' 리스트에 있다. Y N
B2 SAF의 보완 아이템에 대한 대리승인. 브리지는 카드에 대한 새 요청을 처리하면서 SAF내 카드에 대한 현재 보완 거래를 확인한다. 예컨대, 비활성화 요청을 받고 활성화 요청이 SAF에 계류중이면, 현재 요청을 SAF에 두어 인가자가 적절한 주문으로 요청을 받도록 해야 한다. Y N
B3 브리지 서스펜션시의 대리승인. 브리지는 'consecutive-timeouts' 세팅에 도달해 'suspend' 모드에 있고; PC가 'retry-transaction-codes' 리스트에 있다. Y N
B4 Forcee Approval/Reversal Accepted. 브리지는 고객으로부터 0400형 메시지(무효나 다른 시스템생성 취소)를 받고 이것을 'accept'할 수 있다(즉, 후속 배달을 위해 SAD에 직접 둘 수 있다).
(주: 고객에게 받은 스윕 리로드의 모든 0400에 관련된 예오처리가 있다. 이런 거래요청들을 직접 SAF에 두지 않고, 브리지가 'one shot live'를 할 수 있다(즉, 즉시인도를 할 수 있다). 이런 첫번째 시도로 retry 상태를 히트하면, 'B4' 규칙이 적용될 수 있다. 		Y Y
B5 승인 복제. 브리지가 고객의 새로운 비활성화 요청을 처리하는 동안 SAF의 카드에 대한 비활성화 요청을 확인한다. Y N
B6 멀티플렉스 차단 승인. 브리지에서 인가자까지의 모든 라인들이 현채 차단되고; PC가 'retry-transaction-codes' 리스트에 있다. Y N
B0, B1, B2, B3, B6 코드에 대해 고객의 어플은 상품을 24시간내에 사용할 수 있을 것이라고 고객에게 (음성이나 영수증의 인쇄로) 알려주도록 POS 시스템에 명령해야 한다.
브리지의 거절상태가 'Dx' 형태로 있을 수 있다. 고객의 어플은 RC='Dx'인 모든 응답을 거절로 취급할 수 있다. 아래 표는 D 상태 거절코드에 대한 설명이다.
코드 의미 SAF 취소
D1 펜딩 SAF의 거절. 브리지는 고객의 새 활성화 요청을 처리하면서 SAF내카드에 대한 펜딩 활성화요청을 확인했다. N N
D2 쿼리 원격 호스트 타임아웃시의 거절. 브리지는 인가자의 응답을 대기하면서 타임아웃되고, PC가 'retry-transaction-codes' 리스트에 없다. Y Y
D3 브리지 서스펜션에 대한 거절. 브리지는 'consecutive-timeouts' txld에 도달해 'suspend' 모드에 있고, PC가 'retry-transaction-codes'리스트에 없다. N N
D4 멀티플렉서 차단시의 거절. 브리지에서 인가자까지의 모든 루트가 차단됨. N N
D5 브리지 임계오차시의 거절. 브리지는 소정의 임계기간에 닿기 전에 외부 인가를 위한 거래를 할 수 없었고; 백업보호가 되었다. N N
D6 최소금액보다 작은 UPC의 거절. 이 옵션 코드는 UPC에 대해 소정의 최소금액보다 작은 금액의 요청때문에 다른 SAF-able 거래결과는 취할 수 없는 시나리오를 나타낸다. N N
D7 최대금액보다 큰 UPC의 거절. 이 옵션 코드는 UPC에 대해 소정의 최대금액보다 큰 금액의 요청때문에 다른 SAF-able 거래결과는 취할 수 없는 시나리오를 나타낸다. N N
D8 SAF에 비활성인 아이템; 소프트 거절시의 대리승인이 안됨. 이 옵션코드는 고객제공 파일에 'SAF=N'으로 표시된 아이템으로 인해 소프트 거절에 대한 SAF-able 거래결과는 취할 수 없는 시나리오를 나타낸다. V N
D9 SAF에 비활성인 아이템; 타임아웃시의 대리승인이 안됨. 이 옵션코드는 고객제공 파일에 'SAF=N'으로 표시된 아이템으로 인해 소프트 거절에 대한 SAF-able 거래결과는 취할 수 없는 시나리오를 나타낸다. Y Y
DA Swipe Reload시의 거절. 이 코드는 다른 SAF-able 거래결과는 swipe reload 제한으로 인해 취할 수 없음을 표시하는데 사용된다. V N
POS 디스플레이에 거절 문장이 제시될 수 있다. 예컨대, D1 코드의 경우 "Original request accepted" 문장이 디스플레이되고, D2 내지 D5와 D8 내지 DA 코드의 경우 "Try again momentarily" 문장이 디스플레이될 수 있다. D6나 D7 코드의 경우, "Amount incorrect for product"가 디스플레이될 수 있다.
데이터베이스 테이블 정의
브리지가 거래 로그("tranlog') 테이블에 결과와 계량 정보를 기록할 수 있다. 브리지는 SAF를 작동시키는지 여부로 모든 거래에 대한 트랜로그 기록을 쓰는 곳에 "heavier"를, 또는 SAF를 작동시키는 거래에 대해서만 트랜로그 기록을 쓰는 곳에 "lighter"를 운용하도록 구성될 수 있다. 이 선택은 주거래 매니저의 CreatTranLog participant의 'log-safed-only' 속성을 통해 전달된다:
Figure 112018066593417-pct00007
Figure 112018066593417-pct00008
브리지와 그 특성을 구성할 때, 고객이 거래기간 전체에 미치는 브리지의 영향의 기록된 증거를 원하면 고객이 더 무거운 구성을 선택하고(value='false'). 반대로 고객이 거래 터치와 해당 데이터베이스 유지관리 양쪽에서 브리지의 영향을 최소화하고 싶으면 더 가벼운 구성을 선택할 수 있다(vlaue='true'). 본 발명에서는 'tranlog' 테이블이 아래와 같이 정의될 수 있다:
Figure 112018066593417-pct00009
이하 tranlog에 규정된 속성을 설명한다.
id
MS SQL 서버에서 자동 생성된 행 ID
date
SAF 테이블에 엔트리가 기록된 타임스탬프
주: 'safMeta.created' 값과는 달리, 이런 엔트리들은 초단위로 정상화되지 않을 수 있다(즉, 밀리초가 '000'로 세팅되지 않고 밀리초 레벨의 정확도로 기록될 수 있다.
irc
브리지의 IRC(Internal Result Code). 가치저장카드 프로세서에만 내부값을 사용할 수 있다.
rrc
외부 인가자에 의해 되돌아가는 응답코드인 RRC(Remote Response Code). 이 값은 첫번째나 실시간 요청에 대해 인가자에 의해 되돌아갈 수 있다. 후속 RRC들은 'safMeta.lastRRC'에 둔 SAF-ed 요청에 대한 응답으로 인가자로부터 되돌아갈 수 있다.
rc
브리지가 실시간 응답으로 고객의 호스트에 되돌릴 수 있는 RC(Response Code). 이 값은 외부 인가자가 지원하는 것이거나, 브리지가 중재하는 상황에서 Bridge-generatorRC State 값들 중의 하나일 수 있다.
duration
브리지가 수신한 시간부터 트랜로그에 기록된 시간까지의 기간(ms). 모든 "off-box" 성분들을 포함할 수 있음(다음 2개값 참조).
extDuration
브리지가 수신한 시간부터 응답을 위해 대기하고 있는 시간까지의 기간(ms). 'extDuration' 값이 'duration' 값에 합쳐질 수 있다.
주: 상황에 따라서는, 브리지가 거래에 대한 국부적 결정을 하고 외부 인가자를 관련시키지 않을 수 있다. 이 경우, extDuration은 0으로 기록됨.
outstanding
아이템을 서비스했을 때 MAIN.TXN 거래큐의 깊이. 양호한 기능을 할 때, 이 값은 보통 '0'이나 작은 수이다. 더 큰 수는 더 많은 세선들이 메인 트랜잭션 매니저에 구성되어야 하거나 외부 인가자가 피크기간 동안 아주 천천히 요청에 응답함을 표시한다.
node
거래를 처리한 서버의 풀네임
pc
외부 인가자로 보내진 요청의 프로세싱코드ISO8583 필드3). 예컨대, '189090'(활성화), '199090'(리로드), '289090'(비활성화)와 같은 PC 값들을 가치저장카드 프로세서가 사용할 수 있다.
extrc
필요할 때 공급된, 특정 미승인 RC들의 추가 설명문장
peerDuration
피어노드 복제시소요된 거래시간(ms). 브리지는 이 시간 동안 응답을 대기할 수 있다. 'peerDuration' 값은 'duration' 값에 합쳐진다. 거래가 SAF에 있지 않으면 peerDuration이 0이다. 복제는 필요없다.
SAF에서 나오는 아웃바운드 요청에서의 STAN 변경, 특정 프로세싱에 간련된 엔트리들에 대한 SAF 큐의 체크와 같은 특정 조건들을 충족시키기 위해, 브리지의 실시간 프로세싱 엔진은 2개의 관련된 데이터베이스 테이블은 safMeta 테이블과 safdata 테이블에 'SAF-able' 아이템들을 업데이트할 수 있다.
sefMeta 테이블은 SAF 엔트리(예; 엔드포인트)에 관한 '메타' 데이터와 브리지가 SAF 시도(예; 'lastSent', 'lastStan') 후에 업데이트할 수 있는 값인 엔트리에 관련된 동적데이터를 갖는다. 또, 브리지가 SAF 기반 데이터베이스 쿼리의 일부로 사용하는 모든 필드는 이런 '메타' 테이블에 놓여야 한다.
마찬가지로, sefData 테이블은 SAF 요청의 보안표현은 물론 엔트리(예; 'reversal', 'inboundStan')에 관한 정적인 데이터를 포함할 수 있다.
아래 상황에서 이들 테이블의 행의 라이팅이 일어날 수 있다: (a) 브리지의 'retry-response-codes'로 RRC가 리스트되고 'retry-transaction-codes'에 이 거래의 해당 거래코드가 리스트된 거래응답을 인가자로부터 받거나; (b) 인가자로부터 어떤 거래응답도 받지 않았고(즉, 타임아웃 발생) 이 거래의 해당거래코드가 'retry-transaction-codes'에 리스트되거나; (c)거래요청을 준비할 때 인가자에 대한 모든 라인들이 끊어졌고(멀티플렉서 차단 시나리오) 브리지 고객이 시스템을 'saf-on-disconnect' 내지 'true'로 설정했음을 알았거나; (d) 고객에게서 요청을 받고 SAF 테이블내의 동일한 카드에 대한 보완 미송부 요청이 있거나; (e) 인가자로부터 거래응답을 받지 않았고(즉, 타임아웃 발생) 이 거래의 해당 거래코드가 'retry-transaction-codes'에 리스트되지 않거나(또는 브리지가 확인하지 않은 요청을 Swipe Reload로 리스트하거나); (f) 터미널 기반 타임아웃 취소나 고객 무효/취소를 POS로부터 받음. (a) 내지 (e)를 '호스트 기반 타임아웃 취소'라 하여 TOR이라고도 한다.
(a) 내지 (d) 상황에서, 원거래는 테이블에 쓴 아이템이고 이 행의 취소 열은 'false'로 설정할 수 있다. (e) 상황에서는, 원거래의 취소가 테이블에 쓴 아이템이고 이 행의 취소 열은 'true'로 설정할 수 있다. (f)에서는 원거래의 취소를 POS로부터 직접 받고 이 아이템을 테이블에 쓰며 이 행의 취소 열은 'true'로 설정한다. 각각의 상황에서, 실시간 프로세싱 엔진에 의해 첫번째로 테이블에 기록되었을 때의 아이템의 상태를 'RETRY'로 설정한다.
이어서 비동기적으로, 브리지의 SAF 매니저가 이 테이블을 읽고 어떤 행이 아직 배달할 수 있는 후보를 갖는지 결정한다. 가능한 후보는 아이템이 (i) 만료되지 않고; (ii) 최대 리트라이 시도 횟수에 도달하지 않았으며; 및/또는 이전 전송시도 동안 예외처리하지 않은 것일 수 있다.
본 발명에서, 'safMeta' 테이블을 아래와 같이 정의할 수도 있다:
Figure 112018066593417-pct00010
Figure 112018066593417-pct00011
Figure 112018066593417-pct00012
이하 safMeta 테이블에 있는 속성에 대해 설명한다.
id
MS SQL 서버에서 자동으로 생성될 수 있는 행 ID.
tranid
관련 브리지 트랜로그 엔트리의 'id' 값
node
스위치 사례에서의 인가자의 엔드포인트 명칭. 이 값은 'tranlog.endpoint'에 로그된 것과 일치할 수 있고, SAF 관련 테이블들이 하나 이상의 외부 인터페이스를 위한 엔트리들을 가질 수 있기 때문에 여기에도 라이트될 수 있다.
hash
거래요청에 포함된 가치저장카드 상품의 PAN(primary account number)의 비가역적 SHA-512 솔티드 해시(salted hash). 이 값은 같은 PAN을 갖는 활성 아이템들(status='RETRY' or 'PEND')이 SAF 테이블에 남아있는 모든 PAN에 대한 실시간 요청의 전송 방지에 도움을 주는데 중요할 수 있다. 이런 제한 때문에 차단될 수 있는 실시간 요청들은 'D1'의 브리지 생성 RC 거절코드를 받을 수 있다.
status
RETRY: 라이트되었을 때(또는 RC가 'retry' 리스트에 있을 때 업데이트된) 엔트리의 초기 상태
PEND: 엔트리가 운항중이거나 응답대기중
MAX: 엔트리가 최대 retry 카운트에 도달
EXP: 엔트리가 만료되었음
TAKEN: 엔트리가 유효 RC(또는 'retry' 리스트에 규정되지 않은 것)을 받음
ISOEX: 엔트리가 처리하는 동안 예외를 생성
created
엔트리가 SAF 테이블에 처음 라이트되었을 때의 타임스탬프. 이 엔트리는 컬럼이 색인요소로 유효하게 사용될 수 있도록 초 단위로 로그하도록 정상화될 수 있다.
pc
외부 인가자에게 보내진 요청(request)의 프로세싱 코드('PC' ISO8583 필드 3)
lastsent
엔트리를 인가자에게 마지막으로 보냈을 때의 타임스탬프
lastRRC
라스트 리트라이 요청에 대한 응답으로부터 취한 (외부 인가자에 의해 제공될 수 있는 결과코드인) RRC(Remote Result Code). 최종 리트라이 요청이 할당된 타임아웃 시간내에 응답을 받지 못하면 이 값이 0으로 설정될 수 있다.
lastStan
최종 SAF 시도를 보낸 노드. 'NORMAL' 연산에서는 각 노드가 자체 SAF 콘텐트의 언로딩을 담당하고, 'SOLO' 모드에서는 양쪽 노드들의 SAF 콘텐트의 언로딩을 담당한다.
lastAuthId
최종 거래응답시 가치저장카드 프로세서나 외부 인가자로부터 받은 인가 ID(필드 38).
attempts
엔트리에 대한 지금까지의 리트라이 횟수
repStatus
(피어 노드에 대한) 복제 시도 상태. 이 값은 기원 노드에만 관련될 수 있다.
RETRY: 테이블에 라이트되었을 때 엔트리의 초기상태; 복제시도가 'SOLO', 'DISC' 또는 'TOUT' 상황을 히트하면 엔트리가 이 상태에 머물 수 있다.
REND: 복제시도가 운항중이고 응답대기중.
SENT: 브리지가 피어노드에 대한 SAF 엔트리를 성공적으로 복제
FAIL: 복제가 실패하고 재시도도 없음
repRetryReason
repStatus='RETRY'이면, 이 컬럼이 why를 표시. repStatus='FAIL'이면 이 필드에 실피원인이 포함될 수 있다. 이 값은 기원 노드에만 관련된다.
SOLO: 노드가 SAF를 창안하거나 업데이트했을 때 'SOLO' 모드로 운용됨
DISC: 노드가 SAF를 창안하거나 업데이트했을 때 피어에 연결되지 않음
TOUT: 노드가 복제요청 응답을 대기하면서 피어를 타임아웃
NOFF: 노드가 피어에서의 엔트리를 업데이트하지만, 피어는 엔트리를 찾을 수 없다고 보고. 이것은 repStatus='FAIL'와 함께 사용됨
repPhase
피어 노드에 대한 복제 시도의 위상. 이 값은 기원 노드에만 관련된다.
O: Original - 예컨대 브리지가 거래에 대한 첫번째 결정을 할 때 노드가 SAF 엔트리의 오리지널 사례를 복제하거나 복제시도했음.
U: Update - 예컨대 SAF-ed 요청에 대해 인가자로부터 승인을 받았을 때 노드가 오리지널 사례를 복제하거나 시도했음.
repTime
브리지가 엔트리에 대한 복제시도를 마지막으로 시작했을 때의 타임스탬프
archiveId
아카이브 파일에 이 기록을 라이트 한 아카이브 잡 런의 ID
extractId
예외 파일에 이 기록을 보낼지 여부를 결정한 익스트랙트 잡 런의 ID. 익스트랙트 잡은 예외인 모든 완성된 기록을 표시할 수 있다(즉, 상태가 'EXP', 'XAX' 또는 'ISOEX'이거나; 상태가 'TAKEN'이고 lastRRC가 +reconId(예; 156)로서 '00'이 아닐 경우). 익스트랙트 잡이 예외가 아닌 모든 완성된 기록을 표시할 수 있다(즉, 상태가 'TAKEN'이고 lastRRC가 -reconId(예; -156)로서 '00'인 경우). 익스트랙트 잡이 모든 불완전한 기록(즉, 상태가 'RETRY'나 'PEND')을 표시하지 않을 수 있다.
전술한 바와 같이, safData 테이블은 아래와 같다:
Figure 112018066593417-pct00013
Figure 112018066593417-pct00014
safMeta 테이블의 속성은 아래와 같다:
Id
'safMeta'용의 MS SQL 서버에서 자동으로 생성되는 행 ID
secureData
인가자에게 보내질 완성된 SAF-ed 요청의 암호버전. 브리지는 예컨대 거래 접근을 할 때마다 트리플 DES Derived Unique Key를 특징으로 하는 PA-DSS-certified 방식을 이용해 데이터를 암호화할 수 있다.
keyId
브리지의 암호화 방법을 이용해 secureData 행의 콘텐트를 암호화하는데 사용된 BDK(base derivation key)의 식별자.
reversal
아이템이 재시도할 오리지널 거래요청 시도인지('FALSE'로 설정) 또는 오리지널 시도의 취소인지('TRUE'로 설정) 표시하는 플래그.
inboundStan
원래의 인바운드 요청에서 ISO8583 필드 11에서 브리지가 받은 STAN. 모든 당사자들이 거래를 성사시키도록 하는 보고를 하도록 STAN이 여기에 기록될 수 있다.
RRN
원래의 인바운드 요청에서 ISO8583 필드 36에서 브리지가 받은 RRN(retrieval reference number). 모든 당사자 사이의 화해 촉진을 위해 기록될 수도 있다.
amount
거래요청 금액(달러). 이 컬럼에서 고객이 주어진 시간에 미지급 거래의 금액에 대해 SQL 쿼리들을 운용할 수 있다.
도 3은 브리지(30)의 역할과 동작에 관련하여 각종 거래 흐름은 물론 다른 거래 당사자와 관련된 브리지의 역할을 보여준다. POS(311) 및/또는 호스트(312)를 갖춘 고객(310)에게서 거래가 시작된다. POS(311)는 호스트(312)를 통해 브리지(320)로 흐르는 거래를 시작할 수 있다. 이 거래는 브리지(320)를 통해 가치저장카드 프로세서(330)로 배달된다. 가치저장카드 프로세서(330)는 예컨대 서비스 제공자(340)와의 통신을 통해 거래를 처리하고 브리지(320)와 호스트(312)를 통해 POS(311)에 응답을 보낸다. 각각의 흐름에서, 브리지(320)는 요청와 관련 응답에 관한 것 외의 다른 거래에 가치를 추가하지 않는다.
구체적으로 350의 승인거래 흐름에서는 가치저장카드 프로세서나 최종 서비스제공자에 의해 거래가 승인된다. 이 흐름은 POS(311)에서 시작해 호스트(312)와 브리지(320)를 거쳐 가치저장카드 프로세서(330)로 흐른다. 프로세서(330)는 00의 RC를 제공하고, 브리지는 이 RC를 호스트(312)를 통해 POS(311)로 보낸다.
360의 하드 거절 거래는 POS(311)에서 시작해 호스트(312)와 브리지(320)를 거쳐 프로세서(330)로 흐르며, 프로세서(330)는 14의 RC를 제공하고, 브리지(320)는 이 RC를 호스트(312)를 통해 POS(311)에 보낸다.
370의 소프트 거절에서는 'retry list' 거래에 없는 프로세싱 코드가 보인다. 이 흐름도 POS(311)에서 시작해 호스트와 브리지를 거쳐 프로세서(330)로 보내진다. 프로세서(330)는 96의 RC를 제공하고, 브리지(320)는 이 RC를 호스트(312)를 거쳐 POS(311)에 보낸다.
도 4는 대리승인(SAF=00)을 하는 소프트 거절의 거래흐름(40)으로서, 가치저장카드 프로세서에 의해 소프트 거절이 되고, 이 거래는 'retry-transaction-code' 리스트에 설정된다. 따라서, 브리지는 이 아이템을 SAF 큐에 두고 고객에 대한 RC를 바꿔 'B0'- 대리승인 메시지를 반영한다. 그 결과 이 거래와는 비동기적으로, 브리지는 이 아이템의 SAF-ed 요청을 가치저장카드 프로세서에 보낸다. 첫번째 시도는 96의 RC와 함께 거절되지만, SAF 거래매니저가 메인(실시간) 거래매니저와 같은 구성 규칙을 EK르기 때문에, 각각의 "소프트 거절" 응답이 적어도 설정된 최대 시도횟수나 할당 시간까지의 다른 시도를 가져올 수 있다. 거래가 성공하면(즉, 인가자나 가치저장카드 프로세서가 승인하면), 이 아이템은 'TAKEN'으로 표시되고 미래의 SAF 언로딩 액션 대상에서 빠진다.
도 4에서는 고객(410)에게서 거래가 시작되고, 고객 POS(411)가 거래요청(450)을 호스트(412)를 통해 브리지(420)에 보낸다. 브리지(420)는 이 거래를 가치저장카드 프로세서(430)에 보내려 한다. 브리지(420)가 451로 표시된 RC 96의 소프트 거절을 받으면 아이템의 상태를 'RETRY'로 설정하고, 459에서 RC를 B0으로 설정하며 POS(411)에서 "This product will be available within 24 hous"라고 고객에게 알려주도록 한다.
이 거래가 브리지(420)의 SAF 큐(470)로 보내지고, 453에서 거래가 재시도되며, 454에서 RC=96이 되며, 한번더 소프트 거절이 된다. 이 거래는 455에서 'RETRY'로 표시되고, 456에서 재시도되어 457에서 RC=96을 다시 받는다. 또, 458에서 'RETRY'로 표시되고, 459에서 재시도되어 성공적으로 수행될 수 있다. 460에서 RC=00으로 돌아간 다음, 'TAKEN'으로 표시되고 SAF 큐에서 빠질 수 있다.
도 5는 대리승인과 SAF=하드거절을 하는 소프트 거절(50)을 보여준다. 일반적으로 가치저장카드 프로세서나 최종 서비스제공자에 의해 소프트 거절이 되고, 이 거절은 'retry-transaction-code' 리스트에서 다시 설정된다. 따라서, 브리지가 이 거절에 대한 대리승인을 하고 SAF 큐에 이 아이템을 두고 B0의 POS에 RC 코드를 보고한다. 이어서 잠재적인 비동기적으로, 브리지가 이 아이템의 SAF-ed 요청을 가치저장카드 프로세서에 보낸다. 이 아이템을 승인하려는 2회의 시도가 추가적인 소프트 거절들을 받을 수 있다. 세번째 시도는 가치저장카드 프로세서로부터 하드 거절을 받고, 이 아이템은 SAF 큐에서 빠진 다음 예외 파일에 들어가야 한다.
고객(510)에게서 시작된 거래에서, 고객의 POS(511)가 거래요청(550)을 호스트를 통해 브리지(520)에 보내며, 전과 마찬가지로 브리지(520)는 가치저장카드 프로세서(530)에 거리를 보내려 한다. 브리지(520)가 551에서 RC=96의 소프트 거절을 받으면 아이템의 상태를 'RETRY'로 설정하고 559에서 RC를 B0로 설정하며, "This product will be available for use within 24 hours"라고 POS(511)가 구매자에게 알려주도록 한다.
이 거래는 브리지(520)의 SAF 큐(570)로 보내지고, 554에서 재시도되며 555에서 RC=96으로 되고, 한번더 소프트 거절이 된다. 556에서 'RETRY'로 표시되고, 557에서 거래가 재시되되며 558에서 RC=96을 받고 다시 559에서 'RETRY'로 표시된다. 560에서 거래가 재시도된 다음 561에서 RC=14로 하드 거절을 받는다. 562에서 아이템에 'TAKEN' 표시가 붇고 SAF 큐(570)에서 빠진다. 가치저장카드 프로세서(530)의 하드 거절이기 때문에, 이 아이템은 예외 파일에 들어가야 한다.
도 6은 브리지 대리승인에 의한 소프트 거절 시나리오(60)로서, SAF가 최대 재시도 횟수를 한 것을 보여준다. 일반적으로 가치저장카드 프로세서나 최종 서비스제공자가 "소프트 거절(soft declined)"을 하지만, 이 거래는 'retry-transaction-code' 리스트로 설정될 수 있다. 브리지는 이 아이템을 SAF 큐에 두고 대리승인을 하여 RC를 'B0'로 바꾼다. 이어서 비동기적으로, 브리지가 이 아이템의 SAF-ed 요청을 가치저장카드 프로세서에 보낸다. 여기서는 브리지가 승인이나 하드 거절을 받는데 실패하고 최대 시도횟수에 이를 수 있다. 결국, SAF 매니저는 'max-transactions' 임계치가 만족된 것을 인식한다. 성공적인 시도 이전에, SAF 매니저는 이 아이템에 'MAX' 표시를 하고 미래의 SAF 언로딩 액션 대상에서 빠진다. 이 아이템이 예외 파일에 들어갈 수도 있다.
고객 POS(611)가 호스트(612)를 통해 거래요청(650)을 브리지로 보내고, 브리지는 프로세서(630)에 거래를 보내려 한다. 브리지(620)가 651에서 RC=96의 소프트 거절을 받으면 652에서 아이템의 상태를 'RETRY'로 설정하고 653에서 RC를 B0으로 설정한 다음, "This product will be availabel for use within 24 hours"라고 POS(611)가 구매자에게 통지하도록 한다.
이어서 이 거래는 브리지(620)의 SAF 큐(670)로 보내지고, 654에서 거래가 재시도되며 655에서 RC=96으로 되어 한번더 소프트 거절을 통지하고, 고래는 656에서 'RETRY'로 표시된다. 657에서 거래가 재시도되어 658에서 RC=96을 다시 받고, 659에서 'RETRY'로 표시된다. 660에서 가능한 최대 시도횟수에 달하고, 661에서 'MAX'로 표시된다. 이 지점에서 SAF 매니저는 이 아이템을 삭제한다. 가치저장카드 프로세서(630)로부터의 최종 승인이나 거절 없이 최대 시도횟수에 도달해, 이 아이템은 예외 파일에 들어가야 한다.
도 7은 대리승인을 한 호스트 타임아웃 시나리오(70)의 일례로서, 브리지에 의한 2가지 상황, 즉 프로세싱 코드가 'retry' 리스트에 없는 첫번째 상황과 있는 두번째 상황을 보여준다. 첫번째 상황에서, 거절을 받고 RC=D2이다. 취소요청이 생겨 SAF로 보내진 다음 가치저장카드 프로세서로 보내진다. 두번째 상황에서, 브리지는 이 요청을 타임아웃하지만 RC=B1인 대리승인을 기록할 수 있다. SAF-ed 요청이 가치저장카드 프로세서에 의해 받아들여 승인될 때까지 이 프로세서로 보내지고, 이 경우 이 아이템이 'TAKEN'으로 표시되고 미래 SAF 언로딩 액션 대상에서 빠진다.
고객 POS(711)는 호스트(712)를 통해 브리지(720)에 거래요청(750)을 보내고, 가치저장카드 프로세서(730)에 보내고자 한다. 브리지(720)가 751에서 타임아웃하면 상태가 'RETRY'로 되고, 752에서 취소가 'TRUE'로 설정된다. 브리지는 이어서 753에서 RC=D2를 전달해, POS(711)에 "try again momentarily"를 보낸다.
그러나, 754에서 호스트 타임아웃이 다른 출력을 받을 수 있다. 여기서, 타임아웃(755)이 일어날 수 있고, 상태가 'RETRY'로 다시 설정될 수 있어도 736에서 취소는 'FALSE'로 설정된다. 757에서 POS에 RC=B1이 보내지면 구매자에게 "this product will be available for use in 24 hours"가 전달된다. 758에서 SAF 큐(770)가 거래를 다시 하려고 하고 759에서 다시 타임아웃된다. 760에서 이 아이템이 다시 'RETRY'로 표시된다. 761에서 브리지는 거래를 재시도하려고 하고 이때 가치저장카드 프로세서로부터 소프트 거절을 받고 762에서 RC=96으로 된다 이 아이템은 763에서 다시 'RETRY'로 표시된다. 끝으로, 764에서 거래가 시행되고 RC=00이 복귀되어, 거래가 성공했음을 표시한다. 766에서 이 아이템은 'TAKEN'으로 표시되고 SAF 큐(770)에서 빠진다.
도 8은 브리지의 대리승인과 호스트 타임아웃과 최대 시도횟수가 있는 시나리오로서, POS에서 브리지에 거래요청을 보내고, 이 요청이 타임아웃될 수 잇다. 이어서, 브리지는 이 아이템을 SAF 큐에 두고, 대리승인을 하며 RC=B1을 POS에 다시 보고한다. 이어서, 브리지는 이 아이템의 SAF-ed 요청을 가치저장카드 프로세서에 보낸다. 첫번째 시도는 타임아웃이고; 두번째 시도는 소프트 거절을 받는다. 모든 후속 시도들은 타임아웃이거나 소프트 거절이다. 결국, SAF 매니저는 SAF 엔트리의 생성('safMeta.created') 사이의 시간이 이제 'expired-after'로 규정된 시간을 넘었음을 인식한 다음, 이 아이템을 'EXP'로 표시하고 미래의 SAF 언로딩 액션의 대상에서 제외한다. 이 아이템은 예외파일에 들어가야 한다.
고객에서 시작해 고객 POS(811)가 호스트(812)를 통해 브리지(820)에 거래요청(850)을 보낸다. 브리지(820)는 이 거래를 가치저장카드 프로세서(830)에 보내려 한다. 브리지(820)가 851처럼 타암이웃이면, 아이템의 상태를 'RETRY'로 하고, 852에서 reversal='FALSE'로, 853에서 RC=B1으로 하고, "This product will be available for use within 24 hours"라고 POS(811)가 구매자에게 통지하도록 한다.
브리지(820)의 SAF 큐(870)로 보내진 거래는 854에서 재시도되고, 855에서 다시 타임아웃된다. 이 아이템은 856에서 'RETRY'로 표시된다. 857dpt 거래가 재시도되고, 858에서 RC=96을 받는다. 이 거래는 859에서 다시 'RETRY'로 표시되고, 861에서 다시 타임아웃된 다음, 862에서 다시 'RETRY'로 표시된다. 그러나, 엔트리를 위한 시간이 'expire-after' 시간을 넘은 것으로 인식되어 이 아이템이 863에서 'EXP' 상태로 설정되고, 이때 SAF 매니저는 이 아이템을 큐에서 빼버린다. 가치저장카드 프로세서(830)로부터의 최종승인이나 거절 없이 최대시간에 도달했기 때문에, 이 아이템은 예외파일에 들어가야 한다.
도 8은 서스펜드 모드(80)의 일례로서, 프로세싱코드가 'RETRY' 리스트에 있는 서스펜드 모드를 예로 든다. 프로세싱코드가 'retry' 리스트에 없으면, 브리지는 요청을 타임아웃하고 이 아이템을 SAF 큐에 두며, 대리승인을 하고 고객에게 보고된 RC를 'B1'으로 바꾼다. 브리지는 에코 매니저에 규정된 'max-timeout' 값을 넘는 횟수를 타임아웃할 수 있고, 에코매니저가 브리지를 '서스펜드' 모드에 둘 수 있다.
서스펜드 모듀에서 브리지는 어떤 외부 인가자에게도 문의하지 않고 국부적으로 겨래를 결정할 수 있다. 'retry-transaction-code'에 규정되어 있으면, 브리지는 이런 아이템들을 SAF 큐에 두고 POS에 거래를 보내기 전에 응답코드를 바꾼다. 응답코드가 'B3'(브리지 서스펜션에서의 대리승인)나 'D3'(브리지 서스펜션에서의 거절)로 바뀔 수 잇다. 서스펜드 모드가 바뀔 때까지 브리지는 SAF 엔트리를 언로드하지 않는다. 가치저장카드 프로세서가 "에코" 요청에 응답하면, 브리지는 서스펜드 모드를 나가, 거래요청에 대해 가치저장카드 프로세서에 문의하며, SAF 매니저를 통해 SAF 큐를 언로드한다.
도 9에 의하면, 고객 POS(911)이 호스트(912)를 통해 브리지(920)에 거래요청(950)을 보낸다. 마찬가지로, 브리지(920)는 가치저장카드 프로세서(930)에 거래를 보내려 하고, 951에서처럼 타임아웃되면 아이템의 상태를 'RETRY'로 설정하고 959에서 reversal='FALSE'로, 953에서 RC=B1으로 설정하며, "This product will be available for use within 24 hours"라고 POS(911)가 구매자에게 통보하도록 한다. 955에서 최대 타임아웃 횟수에 이를 때까지 거래가 재시되되고 브리지는 서스펜드 모드로 진입한다.
서스펜드 모드에서, 브리지(920)는 POS(911)로부터 거래요청(954)을 받고, 이 거래를 국부적으로 인가하며 956에서 상태를 'RETRY'로 설정하고, 957에서 'B3'의 응답코드로 돌아간다. 또, 브리지는 가치저장카드 프로세서(930)에 계속해서 에코요청(958)을 보내고, 이런 에코는 959에서 타임아웃된다.
프로세싱코드가 'retry' 리스트에 없으면, 거래(960)가 브리지에 의해 거절되고 'D3'의 RC 코드(브리지 서스펜션에서의 거절)가 발급된다. 어떤 포인트에서는, 가치저장카드 프로세서에 의해 에코(962)가 되돌아갈 수 있다. 브리지(920)는 서스펜드 모드로부터 제거되고, 963과 같은 후속 거래들이 가치저장카드 프로세서(930)로 보내지며 964에서 RC가 '00'인 성공 메시지를 받으며, 이때 브리지(920)는 965에서 POS(911)에 보내진다. 이어서, 966에서 SAF 큐(970)가 언로드되어, 967에서 '00'의 RC 코드를 받고, 968에서 이 아이템을 'TAKEN'으로 표시하여, SAF 큐에서 삭제한다.
도 10의 시나리오(1000)는 발기인 기반 무효와 거절에 관한 것으로, 브리지가 일반적으로 고객 호스트로부터 거절 등급(MTI0400) 메시지를 받는다. 거래요청은 (i) POS에서의 취소/무효나, (ii) 호스트에서의 시스템 타임아웃에 기반한다. 브리지는 이런 요청을 국부적으로 받고, 아이템들을 SAF 큐에 두며 'B4'의 RC로 응답한다(강제 승인/취소 수령). 이어서 비동기적으로, 브리지는 가치저장카드 프로세서에 SAF-ed 요청을 보내고, 이런 재시도가 성공하면 이 아이템을 'TAKEN'으로 표시해 미래 SAF 언로딩 액션 대상에서 제외한다.
고객 POS(1011)에서 호스트(1012)를 통해 브리지(1020)에 거래요청(1050)을 보낸다. 전과는 달리, 브리지(1020)는 가치저장카드 프로세서(1030)에 거래를 보내려하지는 않지만, 1051에서 아이템에 'RETRY' 표시를 하고 1052에서 'B4'의 RC를 되돌린다. POS(1011)는 1053에서 이 응답을 받고, 이어서 이 아이템에 SAF 큐(1060)에 제공되고, 1054에서 가치저장카드 프로세서(1030)에 제공된다. 프로세서(1030)가 인정하면, 1055에서 RC가 '00'으로 설정되고 1056에서 이 아이템을 'TAKEN'으로 표시하여 SAF 큐에서 제외한다.
SAF 테이블의 현재 콘텐트가 브리지의 거래처리 행위에 영향을 주는 시나리오가 있을 수 있다. 예컨대, 브리지가 미리 카드 활성화를 SAF 큐에 두고 이 아이템을 성공적으로 배달했지만 이제 이 카드에 대한 비활성화 요청을 받았다면, 새로운 아이템(비활성화)을 적절한 시간순서에서 SAF 큐에 두는 것이 적절할 수도 있다. 아래 표는 브리지가 SAF 테이블의 펜딩 아이템 콘텐트에 의거하여 특정 판단을 하는 방법에 대한 설명인데, "A"는 활성화, "AR"은 활성화거절, "D"는 비활성화, "DR"은 비활성화거절이다.
요청 상단
SAF
엔트리		 응답
1 A A D1 - 펜딩 SAF에 대한 거절
2 A AR B2 - SAFSO 펜딩 보완 아이템에 대한 대리승인
3 A D B2- SAFSO 펜딩 보완 아이템에 대한 대리승인
4 A DR 상단 3개 SAF 엔트리들이 DR-D-A이면, "Open A" 상태; D1이면 펜딩 SAF에 대한 거절. B2이면 SAF내 펜딩 보완아이템에 대한 대리승인
5 D A B2 - SAF내 펜딩 보완아이템에 대한 대리승인
6 D AR B2 - SAF내 펜딩 보완아이템에 대한 대리승인
7 D D B5 - 복제 승인
8 D DR B2 - SAF내 펜딩 보완아이템에 대한 대리승인
상단 SAF 엔트리들이 카드에 대한 이전 아이템들이 SAF-ed된 것을 의미할 수도 있다. 예컨대, 위의 3번의 경우, SAF 큐에서 비활성화를 끝내는 유일한 방법은 이것을 수행한 활성화를 마찬가지로 SAF에 두는 것이다. 따라서, 위의 3번에서 적어도 A-D-A 순서로 되어야 한다. 실제로는 'card will be active within 24 hours"란 영수증을 받은 카드 바이어가 상품을 바로 사용하고 싶어 카드가 재시되도길 요구할 때 이런 과정이 자주 일어난다. 이때문에 POS에 있는 점원은 상품을 비활성화-재활성화시키는 위치에 있게된다. 그러나, SAF 아이템이 언로드될 때까지는 구매자에게 제시된 결과가 여전히 같을 수 있다.
도 11은 펜딩 SAF 상황(1100)을 보여준다. 이 상황은 가치저장카드 프로세서에 의해 거래가 소프트 거절되고 'retry-transaction-code' 리스트로 거래가 구성될 때 일어난다. 브리지는 이 아이템을 SAF 큐에 두고 RC 코드를 B0(거절에서의 대리승인)로 바꾼다. 브리지는 "this product will be available for use within 24 hours"를 구매자에게 알려주도록 POS에 요청한다. 그러나, 브리지는 같은 상품에 대한 두번째 거래를 받고, SAF 큐를 체크한 다음 SAF 큐에 펜딩 아이템이 있는지 판단한다. 브리지는 따라서 거절을 'D1'으로 기록하고 다시 알려준다. 이어서 비동기적으로, 브리지는 이 아이템의 SAF-ed 요청을 가치저장카드 프로세서에 보낸다.
고객의 POS(1111)이 호스트(1112)를 통해 브리지(1120)에 거래요청(1150)을 보낸다. 브리지(1120)가 가치저장카드 프로세서(1130)에 거래를 보내는데, 1151에서 소프트 거절을 받으면, 1152에서 이 아이템에 'RETRY'를 표시하고 1153에서 RC=B0을 POS에 되돌린 다음, 1154에서 이 아이템을 후처리를 위해 SAF 큐(1170)에 보낸다. 이어서 브리지가 1155에서 같은 카드에 대해 두번째 거래요청을 받으면 이 거래를 가치저장카드 프로세서(1130)에 보내지 않고 1156에서 거절표시인 RC=D1을 발급한다. 이 코드는 1157에서 POS(1111)로 보내지고 "Original request accepted"를 받는다. 이어서, 1158에서 SAF 큐(1170)가 가치저장카드 프로세서(1130)에 거래요청(1158)을 보내고 1159에서 이 거래가 허용되었음을 표시하는 '00'의 RC 코드를 받는다. 1160에서 이 아이템은 'TAKEN'으로 표시되고 SAF 큐(1170)에서 빠진다.
도 12의 시나리오(1200)는 SAF내의 보완 아이템에 관한 것으로, 일반적으로 가치저장카드 프로세서로 보내진 거래가 소프트 거절이 되고 'retry-transaction-code' 리스트에 설정된다. 브리지는 이 아이템을 SAF 큐에 두고 고객에게 보내진 RC를 'B0'(거절에 대한 대리승인)으로 바꾼 다음, 같은 카드에 대한 두번째 거래요청을 받고(이때는 비활성화됨), SAF 큐를 점검하고 펜딩 활성화가 있음을 인식한다. 브리지는 이 아이템을 SAF 큐에 두고 (SAF내 펜딩 보완 아이템에 대한 대리승인인) 'B2'의 RC코드를 고객에게 보고한 다음, 한번더 비활성화를 받는다. 다시 브리지는 SAF 큐를 점검하고 이 큐에 펜딩 비활성화가 있다고 결정한다. 따라서, 브리지는 'B5'(복제 승인)의 RC 코드를 다시 보고한다. 그 결과 비동기적으로, 브리지는 2개 아이템(활성화와 첫번째 비활성화)의 SAF-ed 요청들을 가치저장카드 프로세서에 보낸다.
고객의 POS(1211)가 호스트(1212)를 통해 브리지(1220)에 거래요청(1250)을 보내면, 마찬가지로 브리지가 이 거래요청을 가치저장카드 프로세서(1230)에 보내려 한다. 브리지가 1251에서 소프트 거절을 받으면 1252에서 이 아이템을 'RETRY'로 표시하고 1253에서 B0의 RC 코드를 POS에 보낸다. 1254에서 브리지는 이 아이템을 후처리를 위해 SAF 큐(1270)에 보낸다.
브리지가 1255에서 같은 카드에 대한 두번째 거래요청을 받으면, 이 거래요청을 가치저장카드 프로세서(1230)로 보내지 않고 1256에서 이 아이템을 'RETRY'로 표시하고 1257에서 'B2'의 RC 코드를 발급한 다음, 1258에서 같은 카드에 대한 3번째 거래요청을 받고, 마찬가지로 이 요청을 프로세서(1230)에 보내지 않고 1259에서 'B5'의 RC코드를 보낸다. 그 결과, 1260에서 SAF 큐가 첫번째 아이템을 가치저장카드 프로세서(1230)에 보내고 1261에서 '00'의 RC코드를 받은 다음 1262에서 첫번째 거래아이템을 'TAKEN'으로 표시한다. 1263에서 SAF 큐는 두번째 거래아이템을 가치저장카드 프로세서(1230)에 보내고, 이 프로세서는 이 거래요청을 받고 1264에서 '00'의 RC코드를 보낸다. 1265에서 두번째 아이템이 'TAKEN'으로 표시된다. 2개 아이템 모두 SAF 큐에서 삭제된다.
도 13의 시나리오(1300)는 허용된 최저-최대 범위에 대한 것으로, 일반적으로 허용된 최저값 밑으로나 최대값 위로 상품을 리로드한다. 거래요청은 가치저장카드 프로세서로 보내지고, 이 프로세서는 소프트 거절을 한다. 브리지는 아이템 파일에서의 UPC에 대한 최저/최대 범위를 점검하고, 그 양이 한계값보다 낮거나 높은지 결정한다. 한계값보다 낮으면 브리지는 'D6'(규정된 최저값보다 낮은 UPC에 대한 거절)의 RC코드를 보내고, 최대값보다 높으면 'D7'(규정된 최대값보다 큰 UPC에 대한 거절)의 코드를 보낸다.
고객의 POS(1311)거 호스트(1312)를 통해 브리지(1320)에 거래요청(1350)을 보내면, 브리지는 가치저장카드 프로세서(1330)에 거래요청을 보내려 한다. 그리직가 1351에서 소프트 거절을 받으면 1352에서 UPC 최저/최대 테이블(1354)를 보고 1353에서 'D6'나 'D7'의 RC코드를 보낸다.
도 14는 SAF에 대해 활성이 아닌 UPC의 시나리오(1400)의 일례를 보여준다. 일반적으로 가치저장카드 프로세서에 의해 거래가 소프트 거절이 되고 'retry-transaction-code' 리스트에 구성된다. 브리지는 UPC에서 아이템 파일에 대해 구성된 최저/최대 범위를 점검하여 요청된 값이 범위내에 있는지 판단한다. 브리지는 UPC에 대해 아이템파일에서의 활성 플래그를 점검해 'N'으로 설정된 것을 판단하기도 한다. 따라서, 브리지는 'D8'(아이템이 SAF에 대해 활성이 아님; 소프트 거절에 대한 대리승인이 안됨)의 RC를 보낸다.
여기서 고객의 POS(1411)가 호스트(1412)를 통해 브리지(1420)에 거래요청(1450)을 보내면 브리지가 가치저장카드 프로세서(1430)에 거래요청을 보내려 한다. 브리지가 1451에서 소프트 거절을 받으면 UPC 최저/최대 테이블(1452)를 검토하고 D8의 RC코드를 보낸다.
로깅
모든 브리지 액션들은 비공식적으로 'Q2' 로그라고도 하는 로그파일에 기록된다. 이들 파일을 검사해 고장진단과 이벤트 분석을 시작하는 것이 보통이다. 이런 파일은 리더가 브리지가 어떻게 작업하는지를 이해하는데 도움을 주기도 한다. 각각의 로그가 관리가능한 크기(예; 100MB 이하)로 유지되는 로그 로테이터 서비스가 로그를 관리한다.
로그의 엔트리들은 (부팅중에) 배포하고 (셧다운중에) 취소하는 모든 어플 성분 리스트를 보여준다. '클린' 부팅을 위해 정기적으로 로그를 검사할 수 있는데 이 기능은 어플에 새로운 특징과 기능들을 추가하는 과정에 있을 때 적절하다.
"노멀' 거래를 위한 로깅에는 4가지 엔트리가 있다: (i) (고객의 호스트로부터의) 인바운드 요청; (ii) (외부 인가자에 대한) 아웃바운드 요청; (iii) (외부 인가자로부터의) 인바운드 요청; 및/또는 (iv) (고객의 호스트로 돌아가는) 아웃바운드 요청. 어떤 경우에는, 공간절감과 프로세싱 오버헤드 감축을 위해, 로그에 소정의 적절한 ISO8583 요청과 응답필드(예; PC/3, STAN/11, RRN/37, RC/39)만 디스플레이될 수도 있다.
거래가 SAF-ed되거나 SAF 콘텐트가 업데이트된 후속 액션이 일어나면, 이런 정보가 피어노드에 중계되어 양쪽 노드의 SAF 콘텐트가 동기되어 있을 수 있다. '노멀' 복제 시도시, 로깅으로 인해 2개의 엔트리인 (피어노드로의) 아웃바운드 요청과 (피어노드로부터의) 인바운드 응답이 생긴다. 이 엔트리는 오리지널 복제요청, 즉 요청을 처리한 노드에서 이 아이템이 처음으로 SAF될 때의 요청을 나타낸다.
또, 외부 인가자로의 SAF 시도도 로그될 수 있다. 이 경우 2개의 엔트리인 (외부 인가자로의) 아웃바운드 요청과, (외부 인가자로부터의) 인바운드 응답이 생긴다. 경우에 따라서는, 오리지널 STAN이 유니크 STAN으로 대체되기도 한다. 또, 채널레벨 SAF-ed 요청들이 POS 조건코드내 '01' 표시를 통해 식별될 수 있다.
노드가 SAF 요청을 언로드할 시도를 끝낼 때마다, 대응 피어노드가 알려진다. 대표 코딩내의 다양한 복제요청 필드에 있는 아이템의 예는 아래와 같다: (i) (피어의 safMeta.lastRRC 컬럼에 기록된) SAF 응답에서 인가자에 의해 복귀된 39-응답코드(필드 39); (ii) (피어의 safMeta.lastRRC 컬럼에 기록된) 인가자에 의해 복귀된 105-Auth Id(필드 38); (iii) (safMeta 내부의 유니크 식별자인 노드 + tranId인 모든 shemTKd에서 safMetaso 기록을 찾기위해 필드 123내 노드값과 함께 피어에 의해 사용된) 121 - 요청의 Tranlog ID; (iv) (피어의 safMeta.status 컬럼에 기록된) 122 - 요청 상태; (v) 123 - 요청의 노드(룩업 롤을 위한 위 121 참조); (vi) (피어의 safMeta.attempts 컬럼에 기록된) 125 - 요청에 관련된 업데이트된 시도횟수; (vii) (피어의 safMeta.lastSent 컬럼에 기록된) 126 - 시도횟수; 및/또는 (viii) (피어의 safMeta.lastStan 컬럼에 기록된) 127 - 시도의 최종 STAN.
메인 거래매니저(TM; transaction manager) 요약을 유지할 수도 있다. 예컨대, 실시간 거래정보의 요약을 기록할 수 있다. 이런 거래정보에는 (i) (외부 인가자로의) 아웃바운드 요청; (ii) (고객의 호스트로 돌아가는) 아웃바운드 응답; (iii) 프로파일러(각 거래 참가자에 소요된 시간); (iv) 외부 인가자로부터 받은 RRC(Remote Response Code); (v) SAF 체킹에 관한 이벤트; 및/또는 (vi) SAF 프로세싱이 될 경우 피어로 발성되는 복제요청이 포함되지만, 이에 한정되는 것도 아니다.
(외부 인가자로의) 아웃바운드 요청; (외부 인가자로부터의) 인바운드 응답; (각 거래 참가자에 소요된 시간인) 프로파일러; (피어노드 로의/로부터의) 복제요청/응답; 및 복제상태를 포함한 요약 SAF 시도들이 기록되고 포장될 수 있다.
피어노드에서, 오리지널 노드에 생긴 모든 SAF 활동의 기록이 로그될 수도 있다. 이것은 '복제요청'에 의해 이루어진다. 복제 TM은 오리지널 노드에서 가능한 생성 포인트들로부터 비롯되는 복제요청을 취급하고 아래를 포함한다: (i) 메인 TM - SAF에서 끝나는 아이템들에 대한 실시간 거래 처리중에 (피어로의) '오리지널' 요청들을 생성; (ii) SAF TM - 후속 SAF 언로딩중에 피어로의 '업데이트' 요청 생성; (iii) Sync TM - (피어와의 과다통신/통신중단 후) 오리지널 노드가 피어노드와 동기할 때 '오리지널'이나 '업데이트' 피어 요청 생성; 및/또는 (iv) Retru TM - 메인 TM으로부터의 첫번째 요청이 실패했을 경우의 '오리지널' 피어 요청 생성, 또는 SAF TM이나 Sync TM '업데이트' 피어요청이 실패했을 경우의 '업데이트' 피어요청 생성.
요청은 '오리지널'(즉. 풀 SAF 엔트리)이거나 '업데이트'(즉, 엔트리에 관한 상태나 다른 정보의 변화)일 수 있다. 복제 로직은 ISO 필드 3을 통해 '업데이트'와 '오리지널'을 구분할 수 있다. 요청은 있으면 '오리지널'로 처리되고, 없으면 '업데이트로 처리될 수 있다.
고가용성(HA; High Availability)을 위해, 2개의 노드가 동기상태에 있는 걸 돕고 작동중의 어던 포인트에서도 각각의 역할이 있어야 하는 것을 이해하기 위해 SC(State Controller)를 사용할 수 있다. SC 로그의 상태변화를 기록한다.
또, 로그를 통해 필터링을 적용할 수 있다. '##' 태그나 마커가 있으면 SAF 결정, SAF 이벤트 및 HA State Control에 관한 이벤트들을 요약하기 위해 리더가 로그에 필터를 적용할 수 있다.
지원기능
대리승인 규칙을 바꾸는 기능도 하는 '아이템 파일'을 브리지 고객이 가져올(임포트) 수도 있다. 이 파일은 (한 아이템당 1개의 기록인) 아래 표와 같은 CSV(comma-separated value) 포맷으로 구축된다:
필드 데이터
타입		 길이 설명/용도
UPC AN 12
(고정)		 UPC - 이 값은 활성화 요청의 ISO 8583 필드 53에 나타난다. 이 필드는 UPC 유효화가 가능할 때 필요하다(실용적으로 추천됨)
최저금액 N 8
(가변)		 상품에 대해 허용되는 최저 활성화 금액
최대금액 N 8
(가변)		 상품으로부터 허용되는 최대 활성화 금액
SAF 플래그 AN 1
(고정)		 상품이 대리승인 가능한지와 SAF('Y')/('N')인지 여부
FTP-ing 풀 파일에 의한 아이템 파일 프로세싱을 브리지 고객이 시작할 수 있다. 예컨대, Bridge/spool/item_file/request(a.k.a., 'request' sub-directory)에 파일이 제공될 수 있다. 이 파일의 네이밍 컨벤션은 개시자에게 있지만, 일반적으로 확장자로 '.csv'나 '.txt'를 가져야 한다. 이런 확장자를 갖지 않는 파일은 무시해도 된다. 주기적으로, 예를 들어 60초마다 브리지 어플이 디렉토리 폴링(DirPoll) 시설을 이용한 새로운 임포트 파일의 존재를 체크할 수 있다. 적절한 명칭의 파일이 발견되면, 브리지는 이 파일을 처리를 위해 'request' 서브-디렉토리에서 'run' 서브-디렉토리로 옮길 수 있다. 가져오기 처리 동안, 브리지는 아이템파일 인풋을 이용해 브리지 거래 처리엔진에 의한 후속사용에 대비한 데이터베이스 테이블을 구축할 수 있다.
브리지는 가져오기를 성공했을 때 그 액션을 요약하는 리포트를 만들 수 있다. 이런 리포트들은 'response' 서브-디렉토리에 둘 수 있다. 잘못된 입력 파일을 받았을 때 또는 정상적인 완성이 안되도록 처리하는 모든 이벤트에 대해, 브리지는 그 입력파일의 카피를 'bad' 서브-디렉토리로 옮길 수 있다. 또는, 제대로 끝낼 수 있도록 'archive' 서브-디렉토리로 옮길 수도 있다.
브리지의 OLTP(online transaction processing) 엔진이 아래와 같이 최종 아이템 파일 콘텐트를 이용할 수 있다. 첫째, 아래 조건들 중의 하나가 사실이어서 거래가 대리승인을 위해 SAF-able 여부를 브리지가 결정한다: (i) 노드가 현재 'Suspend Mode'에 있다; (ii) 동일한 카드에 대해 SAF에 하나 이상의 배달되지 않은 보완 아이템이 있다; (iii) 요청이 타임아웃되고 PC가 retry 리스트에 있다; 또는 (iv) 이 요청이 소프트 거절을 받았고 PC가 'retry-pc' 리스트에 있다.
이어서 (a)에 규정된 조건들 중의 하나가 사실이면 브리지는 거래 UPC(ISO 8583 필드 54)가 아이템 테이블에 있는지 체크하고, 있다면 이것이 SAF-able 아이템으로 지정되는지를 체크한다. 아이템 파일에 의거하여, 브리지는 아래 표와 같이 이전 결정을 SAF에 덮어쓴다.
이전 브리지 결정
('SAF')		 조건 새로운 브리지 결정
('SAF Override')
B0
STANDIN_APPROVAL_ON_DECLINE		 아이템파일에 없거나, SAF=N으로 있음 D8
APPLERR_ITEM-INACT_DECLINE
B1
STANDIN_APPROVAL_ON_TIMEOUT		 아이템파일에 없거나, SAF=N으로 있음 D9
APPLERR_ITEM-INACT_TIMEOUT
B2
STANDIN_APPROVAL_ON_SAF		 아이템파일에 없거나, SAF=N으로 있음 D8
APPLERR_ITEM-INACT_DECLINE
B3
STANDIN_APPROVAL_ON_SUSPEND		 아이템파일에 없거나, SAF=N으로 있음 D8
APPLERR_ITEM-INACT_DECLINE
B0~B3 아이템파일에 SAF=Y로 있고 SAF Min보다 작은양 D6
APPLERR_ITEM-LESS
B0~B3 아이템파일에 SAF=Y로 있고 SAF Min보다 큰양 D7
APPLERR_ITEM-MORE
예외파일 프로세싱
브리지는 가치저장카드 프로세서에 보낼 예외파일 콘텐트를 만들 수 있다. 이런 파일들은 하루에 여러번 생성되어 전달되도록 되어있다. SAF 파일의 아이템에 대해 아래 조건들 중의 하나가 사실이면 브리지는 이 품목을 예외파일에 둘 수 있다: (i) 아이템 기간만료(safMeta.status - 'EXP'); (ii) 아이템이 최대 시도횟수에 도달(satMeta.status - 'MAZ'); 또는 (iii) 아이템이 인가자에 의해 하드 거절(safMeta.status - 'TAKEN'이고 lastRRC<>'00'). 예외파일은 파이프-제한 포맷으로 구성되고, 경우에 따라서는 헤더와 트레일러가 필요하기도 하다. 빈파일은 상세레코드(표 7)가 없는 헤더(표 6)와 트레일러(표 8)로 표시되지만, 빈파일이 가치저장카드 프로세서에 보내질 수도 있다.
필드 데이터 타입 길이 설명/용도
타입 AN 고정, 6 'RT0100'
생성일시 N 고정, 14 YYYYMMDDHHMMSS
상세레코드
필드 데이터 타입 길이 설명/용도
타입 AN 고정,6 'RT0200'
거래일시 AN 고정, 17 ISO 8583 Data Element('DE') 13&12 - '2013061912:35:58'와 같은 포맷
저장된 ID AN 가변, 15 ISO 8583 DE 42 our of safData.secureData
단말기 ID AN 가변, 8 ISO 8583 DE 42 our of safData.secureData
사인 N 고정, 1 '1'; Act/Reload/Rev of Deact; -1; Deact/Rev of Act/Rev. of Reload) where Act=189090, Deact=289090, Reload=199090 - SaMeta.pc + safData.reversal
카드금액 N 가변, 12 ISO 8583 DE4 out of safData.secureData or safData.amount
디스카운트 금액 N 가변, 12 미사용. 파일에 비워둠
판매금액 N 가변, 12 미사용. 파일에 비워둠
UPC AN 고정, 12 ISO8583 DE54 out of safData.secureData
통화 AN 고정, 3 ISO8583 DE49 out of safData.secureData
STAN N 고정, 12 (safMeta.lastSTAN에 저장된) 최종 SAF 요청에 브리지가 제공한 System Trace Audit Number(STAN ISO8583 DE11)
Trace ID N 고정, 20 (safMeta.lastAuthld에 저장된) 최종 SAF 응답에 가치저장카드 프로세서가 제공한 승인코드
활성화 데이터 AN 가변, 38 (있다면 소정 상품을 분석하는데 필요할 수 있는) ISO8583 DE35 out of safData.secureData
트레일러 레코드
필드 데이터 타입 길이 설명/용도
타입 AN 고정, 6 'RTO300'
엔드 지정자 AN 고정, 3 'END'
브리지가 예외파일을 생성하면, 파일명은 파일생성시 시스템으로부터의 타임스탬프를 포함하고, 파일이 생성된 execption job run을 반영할 수도 있다.
브리지가 주기적으로 동작하는 보안 FTP 시설을 이용해 이 파일들을 전달할 수 있다. 브리지는 SAF 엔트리가 예외파일에 포함되었는지 여부와 포함되었으면 어느것인지에 관한 (extractId 컬럼의) safMeta 테이블에 기록을 할 수 있다. 아래 표는 테이블 엔트리와 그 의미의 예를 보여준다.
값 값의 일례 설명/용도
<1,000,000 566 최종상태가 'EXP', 'MAX' 또는 'TAKEN'이고 safMeta.lastRRC<>'00'이어서 아이템이 예외임;
노드의 extract jop이 <property name="create-output-file" value="true"/>이어서 아이템이 예외파일에 속함; 또는
기록된 값이 추출값의 현재 반복일 수 있다. 여기서는 추출 프로그램이 566번째 실행됨.
>1,000,000 1000566 아이템의 최종상태가 위의 (i) 내지 (iii) 중의 하나이어서 예외이다. 노드의 extract job이 <property name="create-output-file"value="false"/>로 구성되어 아이템이 예외파일에 속하지 않았다. 기록된 값은 추출값의 현재 반복 + 1000000으로 출력파일이 생성되지 않았음을 표시한다.
<-1,000,000 -1000567 최종상태가 'TAKEN'이고 safMeta.lastRRC='00'이어서 아이템이 예외 dkla.
예외가 아니어서 아이템이 예외파일에 속하지 않았다.
0 0 (i) 아이템이 아직 능동적으로 처리중이거나(상태가 'RETRY' 또는 'PEND'); (ii) 아이템이 최종상태가 되었지만 가능한 추출이 아직 되지 않았기 때문에 아이템이 아직 특성화되지 않았다.

Claims (19)

  1. 소매상 POS(Point-Of-Sale)/호스트에 근접해있고, POS/호스트 및 가치저장카드 프로세서와 선택적으로 통신하는, 국부적 가치저장카드 거래 처리장치에 있어서:
    POS나 호스트와의 선택적 통신을 가능케하는 POS/호스트 인터페이스;
    가치저장카드 프로세서와의 선택적 통신을 가능케하는 가치저장카드 프로세서 인터페이스; 및
    소정의 가치저장카드 거래요청들에 대한 선택적 결정을 하는 프로세싱 모듈;을 포함하고,
    가치저장카드 프로세서와 통신하는 동안, 상기 프로세싱 모듈이 가치저장카드 거래요청들에 대한 결정을 하지 않고 이런 거래요청들을 가치저장카드 프로세서에 보내며;
    가치저장카드 프로세서와 통신하지 않는 동안, 상기 프로세싱 모듈이 가치저장카드 거래요청들에 대해 국부적으로 결정을 하고;
    상기 가치저장카드 거래가 활성화, 비활성화, 리로드 및/또는 리프레시 거래인 것을 특징으로 하는 국부적 가치저장카드 거래 처리장치.
  2. 삭제
  3. 삭제
  4. 제1항에 있어서, 프로세싱 모듈과 가치저장카드 프로세서 사이의 통신이 재설정되면, 프로세싱 모듈이 국부적 가치저장카드 거래 처리장치에 의해 국부적으로 실행된 거래들로 가치저장카드 프로세서에 연계된 메모리를 업데이트하는 것을 특징으로 하는 국부적 가치저장카드 거래 처리장치.
  5. 제1항에 있어서, 가치저장카드 프로세서와 통신하는 동안, 상기 프로세싱 모듈이 가치저장카드 프로세서로부터 받은 응답에 의거하여 가치저장카드 프로세서의 결정들을 국부적으로 덮어쓰는 것을 특징으로 하는 국부적 가치저장카드 거래 처리장치.
  6. 제5항에 있어서, 가치저장카드 타입, 거래 타입 및/또는 거래금액이 덮어쓰기 가능하게 저장되면 가치저장카드 프로세서가 가치저장카드 프로세서의 결정들을 국부적으로 덮어쓰기만 하는 것을 특징으로 하는 국부적 가치저장카드 거래 처리장치.
  7. 제6항에 있어서, 프로세싱 모듈에 의한 결정 덮어쓰기가 소프트 거절(soft decline)인 것을 특징으로 하는 국부적 가치저장카드 거래 처리장치.
  8. 제1항에 있어서, 상기 결정들이 활성화, 비활성화, 리로드 및/또는 리프레시 거래를 포함하는 것을 특징으로 하는 국부적 가치저장카드 거래 처리장치.
  9. 제1항에 있어서, 프로세싱 모듈과 가치저장카드 프로세서 사이의 통신이 재설정되면 국부적 가치저장카드 거래 처리장치에 의해 국부적으로 수행된 거래들로 가치저장카드 프로세서에 연계된 메모리를 업데이트하는 것을 특징으로 하는 국부적 가치저장카드 거래 처리장치.
  10. 제1항에 있어서, 중복저장소를 제공하도록 콘텐트 복제어플과 통신하는 적어도 2개의 데이터베이스를 더 포함하는 것을 특징으로 하는 국부적 가치저장카드 거래 처리장치.
  11. 제1항에 있어서, 상기 국부적 가치저장카드 거래 처리장치가 하나 이상의 로드밸런서나 하나의 멀티플렉서를 통해 POS/호스트와 통신하는 것을 특징으로 하는 국부적 가치저장카드 거래 처리장치.
  12. 소매상 POS(Point-Of-Sale)/호스트, POS/호스트와 함께 국부적으로 배치된 브리지 프로세서, 및 가치저장카드 프로세서 사이에서 이루어지는, 국부적 가치저장카드 거래 승인방법에 있어서:
    상기 브리지 프로세서가 거래요청을 받고, 이런 거래는 가치저장카드 활성화, 비활성화, 리로드 및/또는 리프레시 거래인 단계;
    거래요청이 가치저장카드에 보내졌는지 또는 국부적으로 결정되었는지 여부를 브리지 프로세서가 결정하는 단계;
    거래요청이 가치저장카드 프로세서에 보내졌다고 결정되면, 이런 거래요청을 브리지 프로세서로부터 가치저장카드 프로세서에 보내고, 가치저장카드 프로세서로부터, 또는 가치저장카드 프로세서와의 통신으로부터 소정의 응답을 받았을 때 가치저장카드 프로세서의 응답을 브리지 프로세서가 덮어쓰거나 국부적으로 거래요청을 결정하는 단계;
    거래요청이 가치저장카드 프로세서에 보내지지 않았다고 결정되면, 거래요청을 브리지 프로세서가 국부적으로 결정하는 단계;
    거래요청 응답을 브리지 프로세서가 POS/호스트에 돌려보내는 단계; 및
    프로세싱 모듈과 가치저장카드 프로세서 사이의 통신이 재설정되면 브리지 프로세서에 의해 국부적으로 수행된 거래들로 가치저장카드 프로세서에 연계된 메모리를 업데이트하는 단계;를 포함하는 것을 특징으로 하는 국부적 가치저장카드 거래 승인방법.
  13. 삭제
  14. 제12항에 있어서, 거래요청이 가치저장카드에 보내졌는지 또는 국부적으로 결정되었는지 여부를 브리지 프로세서가 결정하는 단계에서,
    POS/호스트로부터 요청된 거래의 타입을 결정하고;
    거래 및/또는 가치저장카드의 타입과 관련된 프로세싱 코드가 국부적 처리에 맞도록 표시되었는지 여부를 결정하며;
    상기 브리지 프로세서가 가치저장카드 프로세서와 통신중인지 여부를 결정하는 것을 특징으로 하는 국부적 가치저장카드 거래 승인방법.
  15. 제14항에 있어서, 거래 및/또는 가치저장카드의 타입과 관련된 프로세싱 코드가 국부적 처리에 맞도록 표시되지 않았으면 브리지 프로세서가 창구 역할을 하여 거래요청은 가치저장카드 프로세서로 보내고 거래요청에 대한 응답은 POS/호스트에 돌려보내는 것을 특징으로 하는 국부적 가치저장카드 거래 승인방법.
  16. 제12항에 있어서, 브리지 프로세서가 가치저장카드 프로세서와 통신하고 있지 않으면 가치저장카드 프로세서와의 통신이 재설정될 때까지 브리지 프로세서에서 적어도 몇몇 거래들이 국부적으로 수행되는 것을 특징으로 하는 국부적 가치저장카드 거래 승인방법.
  17. 제12항에 있어서, 브리지 프로세서가 가치저장카드 프로세서로부터 받은 타임아웃 후에 거래요청들을 국부적으로 처리하는 것을 특징으로 하는 국부적 가치저장카드 거래 승인방법.
  18. 제12항에 있어서, 가치저장카드 프로세서로부터 받고 브리지 프로세서에 의해 국부적으로 덮어씌워진 응답이 소프트 거절인 것을 특징으로 하는 국부적 가치저장카드 거래 승인방법.
  19. 삭제
KR1020187017162A 2015-11-18 2016-11-14 국부적 거래승인을 위한 네트웍 브리지 KR102113938B1 (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US14/944,319 2015-11-18
US14/944,319 US20170140358A1 (en) 2015-11-18 2015-11-18 Network Bridge for Local Transaction Authorization
PCT/US2016/061930 WO2017087335A1 (en) 2015-11-18 2016-11-14 Network bridge for local transaction authorization

Publications (2)

Publication Number Publication Date
KR20180090827A KR20180090827A (ko) 2018-08-13
KR102113938B1 true KR102113938B1 (ko) 2020-05-21

Family

ID=58691519

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020187017162A KR102113938B1 (ko) 2015-11-18 2016-11-14 국부적 거래승인을 위한 네트웍 브리지

Country Status (14)

Country Link
US (1) US20170140358A1 (ko)
EP (1) EP3378023A4 (ko)
JP (2) JP7114462B2 (ko)
KR (1) KR102113938B1 (ko)
CN (1) CN108463830B (ko)
AU (2) AU2016357267A1 (ko)
BR (1) BR112018010060A2 (ko)
CA (1) CA3005732C (ko)
CO (1) CO2018006101A2 (ko)
HK (1) HK1255076A1 (ko)
IL (1) IL259284B1 (ko)
MX (1) MX2018006137A (ko)
RU (1) RU2715801C2 (ko)
WO (1) WO2017087335A1 (ko)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113196324A (zh) * 2018-12-21 2021-07-30 维萨国际服务协会 经由条件授权进行处理的方法
CN113630301B (zh) * 2021-08-19 2022-11-08 平安科技（深圳）有限公司 基于智能决策的数据传输方法、装置、设备及存储介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010026811A (ja) * 2008-07-18 2010-02-04 Fuji Electric Holdings Co Ltd Ｉｃカード・サービスシステム、そのサービス管理センタ、サービス端末、プログラム
US20130290121A1 (en) * 2011-11-13 2013-10-31 Google Inc. Real-time payment authorization

Family Cites Families (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH07104891B2 (ja) * 1986-08-05 1995-11-13 沖電気工業株式会社 取引処理装置
US5285382A (en) * 1991-02-25 1994-02-08 Keyosk Corporation System and method for processing credit and debit card validity and funds transactions from vending machines and similar terminals
EP1103140A4 (en) 1998-06-03 2003-02-26 Mci Worldcom Inc SALES POINT ACTIVATION AND DATA DEACTIVATION OF PRE-PAID PHONE CARDS
AU2299399A (en) * 1999-02-05 2000-08-25 Kazuo Murayama Data input device and computer system
US8706630B2 (en) * 1999-08-19 2014-04-22 E2Interactive, Inc. System and method for securely authorizing and distributing stored-value card data
US7630926B2 (en) 1999-08-19 2009-12-08 E2Interactive, Inc. Inserting value into customer account at point of sale using a customer account identifier
US7578439B2 (en) * 1999-08-19 2009-08-25 E2Interactive, Inc. System and method for authorizing stored value card transactions
EP1510984A3 (en) * 2000-03-01 2005-06-08 Passgate Corporation Method, system and computer readable medium for web site account and e-commerce management from a central location
US10185936B2 (en) * 2000-06-22 2019-01-22 Jpmorgan Chase Bank, N.A. Method and system for processing internet payments
US20020156727A1 (en) * 2001-01-29 2002-10-24 Levake Mark Method and apparatus for conducting live, point-of-sale, electronic monitoring and transaction services
BR0208337A (pt) * 2001-03-29 2004-03-23 Ebestcard Ltd Sistema de transação por cartão, métodos de processamento de transação por cartão, de manutenção da coerência de dados entre um servidor e um terminal, de determinação sobre se um cartão pode ser usado e de permissão de transações on-line e off-line, terminal de cartão, meio de registro de leitura de computador e tabela de dados
AU2003218178B2 (en) * 2002-03-14 2009-05-21 Euronet Worldwide, Inc. A system and method for purchasing goods and services through data network access points over a point of sale network
KR100531075B1 (ko) * 2002-04-29 2005-11-28 스마텍(주) 대금결재 시스템
US7337351B2 (en) * 2002-09-18 2008-02-26 Netezza Corporation Disk mirror architecture for database appliance with locally balanced regeneration
US20040148258A1 (en) * 2003-01-29 2004-07-29 Tillett Wiley S. Electronic check settlement method
US7437328B2 (en) * 2003-11-14 2008-10-14 E2Interactive, Inc. Value insertion using bill pay card preassociated with biller
JP2006330891A (ja) 2005-05-24 2006-12-07 Konica Minolta Photo Imaging Inc Ｉｄカード作成システム及びｉｄカード作成方法
CN101375294A (zh) * 2005-12-06 2009-02-25 维萨美国股份有限公司 用于对便携式消费设备充值和再充值的方法和系统
WO2007120915A2 (en) * 2006-04-17 2007-10-25 Starent Networks Corporation System and method for traffic localization
JP5080045B2 (ja) * 2006-09-05 2012-11-21 エスアイアイ・データサービス株式会社 電子マネー決済制御装置及び電子マネー決済制御プログラム
US7978599B2 (en) * 2006-11-17 2011-07-12 Cisco Technology, Inc. Method and system to identify and alleviate remote overload
US8109444B2 (en) * 2007-09-12 2012-02-07 Devicefidelity, Inc. Selectively switching antennas of transaction cards
CN101458795A (zh) * 2007-12-14 2009-06-17 哈瑞克思信息科技公司 对移动卡使用离线交易批准模式的支付处理系统及其方法
BRPI1014196A8 (pt) * 2009-03-26 2017-07-25 Nokia Corp Método e aparelho para proporcionar transações de pagamento off-line com transferência de dados mínima
US20110320291A1 (en) * 2010-06-28 2011-12-29 Coon Jonathan C Systems and methods for asynchronous mobile authorization of credit card purchases
KR101527058B1 (ko) * 2010-07-29 2015-06-09 에스케이텔레콤 주식회사 분산 파일 관리 장치 및 방법
US10204327B2 (en) * 2011-02-05 2019-02-12 Visa International Service Association Merchant-consumer bridging platform apparatuses, methods and systems
US20130179352A1 (en) * 2011-03-12 2013-07-11 Mocapay, Inc. Secure wireless transactions when a wireless network is unavailable
US20120323786A1 (en) * 2011-06-16 2012-12-20 OneID Inc. Method and system for delayed authorization of online transactions
US20120330784A1 (en) * 2011-06-22 2012-12-27 Broadcom Corporation Mobile Device for Transaction Payment Delegation
JP5553821B2 (ja) * 2011-12-28 2014-07-16 楽天株式会社 情報処理サーバ、情報処理方法、情報処理プログラム、情報処理プログラムが記録された記録媒体、携帯端末、携帯端末用プログラム、及び携帯端末用プログラムが記録された記録媒体
US20130179281A1 (en) * 2012-01-10 2013-07-11 Mocapay, Inc. System and method for offline stand-in of financial payment transactions
US20130185214A1 (en) * 2012-01-12 2013-07-18 Firethorn Mobile Inc. System and Method For Secure Offline Payment Transactions Using A Portable Computing Device
JP6118090B2 (ja) 2012-12-07 2017-04-19 Ｊｒ東日本メカトロニクス株式会社 リーダーライター装置
US9911110B2 (en) * 2013-03-05 2018-03-06 Square, Inc. Predicting approval of transactions
US10192214B2 (en) * 2013-03-11 2019-01-29 Google Llc Pending deposit for payment processing system
US9836733B2 (en) * 2013-03-15 2017-12-05 Cullinan Consulting Group Pty Ltd. Transaction verification system
US9741035B1 (en) * 2014-12-11 2017-08-22 Square, Inc. Intelligent payment capture in failed authorization requests

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010026811A (ja) * 2008-07-18 2010-02-04 Fuji Electric Holdings Co Ltd Ｉｃカード・サービスシステム、そのサービス管理センタ、サービス端末、プログラム
US20130290121A1 (en) * 2011-11-13 2013-10-31 Google Inc. Real-time payment authorization

Also Published As

Publication number Publication date
WO2017087335A1 (en) 2017-05-26
RU2018121829A (ru) 2019-12-18
CO2018006101A2 (es) 2018-07-10
IL259284A (en) 2018-07-31
JP7114462B2 (ja) 2022-08-08
RU2018121829A3 (ko) 2019-12-18
KR20180090827A (ko) 2018-08-13
HK1255076A1 (zh) 2019-08-02
MX2018006137A (es) 2018-08-15
BR112018010060A2 (pt) 2018-11-13
AU2020204333B2 (en) 2022-03-24
EP3378023A1 (en) 2018-09-26
EP3378023A4 (en) 2019-05-22
RU2715801C2 (ru) 2020-03-03
JP2018537778A (ja) 2018-12-20
CA3005732C (en) 2021-11-09
US20170140358A1 (en) 2017-05-18
CN108463830B (zh) 2022-06-14
AU2016357267A1 (en) 2018-06-07
IL259284B1 (en) 2024-03-01
AU2016357267A8 (en) 2018-12-06
AU2020204333A1 (en) 2020-07-16
CN108463830A (zh) 2018-08-28
WO2017087335A8 (en) 2018-07-05
JP2020184352A (ja) 2020-11-12
CA3005732A1 (en) 2017-05-26
JP7089553B2 (ja) 2022-06-22

Similar Documents

Publication Publication Date Title
US20040128243A1 (en) Transaction processing
CN101076819A (zh) 移动式金融交易管理系统和方法
US20240013175A1 (en) Method and system for universal control account activities
WO2009111562A2 (en) Methods and systems for managing merchant identifiers
CA3056277C (en) System for managing transactional data
US20160239853A1 (en) Method and system for providing insights to merchants based on consumer transaction history
JP7089553B2 (ja) ローカル取引認可のためのネットワークブリッジ
CA3057871C (en) System for pushing transactional data
EP3631733A1 (en) System for accessing transactional data
US20180144338A1 (en) Method and system for controlled access and usage of payment credentials
JP2005242680A (ja) 保険事業システム
TWI740436B (zh) 重點客戶往來對象優惠自動識別系統
US20210374283A1 (en) System for managing transactional data
JP2022162782A (ja) 伝票業務支援方法、伝票業務支援システム、及び伝票業務支援装置
JP2004030410A (ja) 特定サービス提供方法、システム及びプログラム
JP2023167763A (ja) 伝票業務支援方法及び伝票業務支援システム
JP2001067529A (ja) プリペイドカード管理システム
CN115168378A (zh) 一种银行客户信息交易历史的记录方法、装置及设备
JP2008250766A (ja) オペレータ承認条件設定システム

Legal Events

Date Code Title Description
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right