KR20100135268A - 지불 처리 시스템에서의 신뢰 에이전트 식별 - Google Patents

지불 처리 시스템에서의 신뢰 에이전트 식별 Download PDF

Info

Publication number
KR20100135268A
KR20100135268A KR1020107023494A KR20107023494A KR20100135268A KR 20100135268 A KR20100135268 A KR 20100135268A KR 1020107023494 A KR1020107023494 A KR 1020107023494A KR 20107023494 A KR20107023494 A KR 20107023494A KR 20100135268 A KR20100135268 A KR 20100135268A
Authority
KR
South Korea
Prior art keywords
agent
transaction
party
bin
auar
Prior art date
Application number
KR1020107023494A
Other languages
English (en)
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 KR20100135268A publication Critical patent/KR20100135268A/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • 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/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • 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/04—Payment circuits
    • 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/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking 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/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • 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/385—Payment protocols; Details thereof using an alias or single-use codes
    • 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/405—Establishing or using transaction specific rules
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3242—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/50—Oblivious transfer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Finance (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Power Engineering (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Computer And Data Communications (AREA)

Abstract

상인에 대한 트랜잭션을 처리하는 에이전트에 있어서 데이터 보안 요구사항들을 따르는지를 결정한다. 에이전트에 대한 에이전트 고유 계정 결과(AUAR) 및 매입자에게 인가된 은행 식별 번호(BIN)를 포함하는 계정에 관한 트랜잭션을 위해 그 에이전트로부터 허가 요청이 수신된다. 에이전트 식별자 및 그 계정에 대응되는 주 계정 번호(PAN)가 AUAR로부터 유도될 수 있을 때 그 AUAR은 유효하다. PAN이 이러한 대응관계를 결여하거나 또는 그 에이전트 식별자가 다른 에이전트 식별자들 중에서 고유성을 결여할 때 AUAR은 무효하다. AUAR이 무효할 때, 에이전트가 BIN을 사용할 수 있도록 등록되어 있지 않을 때, 그리고 에이전트 식별자가 무효할 때, 매입자는 BIN 및 에이전트의 신원을 수신한다. 에이전트가 BIN을 사용할 수 있도록 등록되어 있지 않을 때, 매입자는 통지받을 것이다.

Description

지불 처리 시스템에서의 신뢰 에이전트 식별{Payment processing system trusted agent identification}
- 관련 출원에 대한 상호-참조(cross-reference)
본 출원은 2008년 3월 21일에 출원된 "Payment Processing System Trusted Agent Identification" 명칭의 미국 출원 번호 제12/052,927호에 대한 우선권을 주장하며, 그 미국 출원의 전체 내용은 참조에 의해 이 문서에 통합된다.
- 본 발명의 기술분야
본 발명의 구현들은 대체적으로 지불 처리 시스템(payment processing system)에 관한 것이고, 더 자세하게는 지불 처리 시스템 내의 신뢰 에이전트(trusted agent)의 식별에 관한 것이다.
전형적인 지불 처리 시스템은 직불 카드(debit card), 신용 카드(credit card) 또는 선불 카드(pre-paid card)나 다른 이러한 기기와 같은 휴대용 소비자 기기를 가진 소비자로서 상인(merchant)에게서 구매를 하는 소비자에게 서비스를 제공한다. 휴대용 소비자 기기는 그와 연관된 계정 번호(account number)를 가지고 있으며 은행이나 다른 기관과 같은 발행자(issuer)에 의해 발행된다. 발행자는, 소비자의 지불을 위해, 구매 항목들과 이에 더하여 어느 정도의 이자(율)(interest) 및 수수료(fees)에 관한 계산서(statement)를 소비자에게 제공한다. 매입자(acquirer)는 구매액에서 어느 정도의 수수료를 뺀 금액에 대하여 상인에게 지불하며, 그리고 차례로 발행자에 의해 지불된다. 이들 트랜잭션(transaction)들은 지불 처리 시스템 - 그 시스템은 전형적으로 트랜잭션 핸들러(handler)에 의해 촉진되며 또한 그 지불 처리 시스템 내의 참여자(participant)들에 대한 비즈니스 규칙들을 확립하고 관리함 - 내에서 일어난다. 그 지불 처리 시스템은, 또한 상인들로부터 트랜잭션 요청들을 수신하며 그리고 매입자 및 지불 처리 시스템에 트랜잭션의 처리를 제공하는 프로세서들을 포함할 수 있다.
전형적인 지불 처리 시스템에서의 상인은 종종 자신의 매입자에게 통지함이 없이 제3자 에이전트(third party agent)의 서비스를 활용한다. 이 제3자 에이전트는 트랜잭션에 관하여 어떤 부가 가치 서비스(value added service)를 수행할 수 있고, 다수의 트랜잭션들을 통합정리(consolidate)하며, 그리고 그 스스로 제3자 에이전트인 프로세서에 이들 다수의 트랜잭션들을 전달할 수 있다. 상인이 제3 에이전트를 사용하여 자신의 트랜잭션 당 비용을 낮추고 있을 수도 있지만, 그 제3자 에이전트로부터 트랜잭션을 받는 프로세서는 상인, 제3자 에이전트 및 매입자 간의 관계를 인식하고 있지 않을 수도 있다. 매입자는 그 매입자의 사용을 위해 그 매입자에 할당된 은행 식별 번호(bank identification number; BIN)들을 사용하고 있는 제3자 에이전트들을 인식하고 있지 않을 수도 있다. 매입자의 사용을 위해 할당된 BIN을 사용할 수 있도록 등록되어 있지 않은 제3자 에이전트들은 지불 처리 시스템의 규정 및/또는 비즈니스 규칙들 밖에서 동작하는 것으로 간주된다.
매입자는 이러한 상인들에 의해 수행되는 트랜잭션을 서비스하는 제3자 에이전트들 및 자신의 피후원 상인들의 활동들에 대하여 책임을 갖는다. 매입자들에게 더 중요한 위험성들 중 하나는 제3자 에이전트가 소비자 데이터를 도난당할 가능성이다. 제3자 에이전트에 관한 이러한 정보유출(compromise) 유형은 소비자의 계정 데이터가 악의적인 해커에 의해 액세스될 때 일어날 수 있고, 아마도 그 소비자의 계정 데이터의 도용이라는 결과를 낳을 것이다. 제3자 에이전트들은 단지 어느 매입자에 의해서도 매입자의 BIN을 사용할 수 있도록 등록되어 있지 않을 수도 있을 뿐 아니라, 제3자 에이전트는 또한 지불 처리 시스템에서 트랜잭션 핸들러에 의해 요구되는 최소 데이터 보안조차도 결여했을 수도 있다.
지불 처리 시스템의 트랜잭션 핸들러의 데이터 보안 요구사항들에 제3자 에이전트들이 따르는 것을 식별하기 위한 기술들이 필요하다.
본 발명의 구현들은 지불 처리 네트워크에서의 트랜잭션을 위한 허가(authorization) 요청을 제3자 에이전트로부터 수신하는 것을 포함한다. 상기 허가 요청은 매입자에게 인가된 은행 식별 번호(BIN) 및 제3자 에이전트에 대한 에이전트 고유 계정 결과(agent unique account result; AUAR)를 포함한다. 상기 AUAR이 유효(valid)한지 또는 무효(invalid)한지 여부에 관한 결과가 결정된다. 주 계정 번호(primary account number; PAN) 및 에이전트 식별자가 상기 AUAR로부터 유도될 수 있을 경우에 상기 AUAR이 유효한데, 여기서 상기 PAN은 상인과의 트랜잭션을 행하는 소비자의 계정에 대응되며 그리고 상기 에이전트 식별자는 다른 상기 제3 에이전트들에 각각 대응되는 다른 에이전트 식별자들에 대하여 상기 지불 처리 네트워크 내에서 고유하다. 상기 PAN이 상기 상인과의 트랜잭션을 행하는 소비자의 계정에 대한 대응관계를 결여할 때 또는 상기 에이전트 식별자가 다른 제3자 에이전트들에 각각 대응되는 다른 에이전트 식별자들에 대하여 상기 지불 처리 네트워크 내에서 고유성을 결여할 때 상기 AUAR은 무효하다. 각각의 에이전트 식별자가 BIN을 사용할 수 있도록 등록되어 있는 상태를 가지는 다수의 에이전트 식별자들을 포함하고 있는 등록 세트 내에 상기 에이전트 식별자를 배치함으로써 상기 제3자 에이전트가 상기 BIN을 사용할 수 있도록 등록되어 있는지 여부에 관한 결과가 결정된다.
상기 에이전트 식별자는 그것이 에이전트 식별자들의 세트 내에 있는 경우 유효한 것으로 그리고 상기 세트 내에 존재하지 않을 때 무효한 것으로 결정될 수 있다. 상기 AUAR이 무효할 때, 상기 제3자 에이전트가 상기 BIN을 사용할 수 있도록 등록되어 있지 않을 때, 그리고 상기 에이전트 식별자가 무효할 때 상기 BIN 및 상기 제3자 에이전트의 아이디가 상기 매입자로의 전송에서 발송될 것이다. 상기 제3자 에이전트가 상기 BIN을 사용할 수 있도록 등록되어 있지 않을 때, 상기 매입자는 통지받을 것이다. 상기 전송은 또한 각각의 에이전트 식별자가 상기 BIN을 사용할 수 있도록 등록되어 있는 상태를 가지는 상기 에이전트 식별자들과 상기 상인을 연관시키기 위한 요청을 포함할 것이다.
또 하나의 구현에서, 지불 처리 시스템에 참여하는 적어도 하나의 제3자 에이전트를 식별한다. 다른 추가적인 구현에서, 컴퓨터 구현 방법은, 제3자 에이전트에 관한 보안 대책 준수(security measure compliance)를 확립하는 단계; 트랜잭션에서 제3자 에이전트에 의해 어떤 은행 식별 번호가 사용되는지를 결정하는 단계; 및 상기 보안 대책 준수에 관한 상기 제3자 에이전트의 상태를 상기 은행 식별 번호와 연관된 매입자에게 통지하는 단계를 포함한다.
다른 추가적인 구현에서, 컴퓨터 구현 방법은, 보안 대책에 따르는 제3자 에이전트들에 대한 레지스트리(registry)를 설립하는 단계; 제3자 에이전트가 상기 보안 대책에 따를 때 상기 제3자 에이전트에게 에이전트 고유 식별자 및 비밀 코드(secret code)를 할당하는 단계; 트랜잭션을 위하여 주 계정 번호와 함께 제3자 에이전트 고유 식별자 및 비밀 코드의 사용을 요구하는 단계; 상기 에이전트 고유 식별자 및 상기 비밀 코드로부터 에이전트 고유 계정 결과를 식별하는 단계; 매입 프로세서에게로 발송되는 어떤 허가 요청 메시지들에서 상기 에이전트 고유 계정 결과를 상기 제3자 에이전트가 발송할 것을 요청하는 단계; 상기 제3자 에이전트에 의해 상기 매입 프로세서에게 발송된 허가 요청 메시지들에서 상기 에이전트 고유 계정 결과를 포함할 것을 상기 매입 프로세서에게 의무화하는 단계; 상기 허가 요청 메시지들을 저장하는 단계; 및 상기 매입자와 연관된 어떤 은행 식별 번호들을 사용하는 상기 매입자의 모든 매입 프로세서들에게 상기 매입자가 사용할 매입 프로세서를 선정하지 않았음을, 그리고 상기 매입자의 은행 식별 번호들을 사용하는 모든 에이전트들에게 이러한 에이전트들이 상기 레지스트리에 등록되어 있지 않음을 주기적으로 보고하는 단계를 포함한다.
다른 또 하나의 구현에서, 트랜잭션 핸들러는 상인과 트랜잭션을 행한 소비자로부터 그 트랜잭션에 대한 지불을 획득할 것을 발행자에게 요청한다. 상기 상인은 매입자에게 상기 트랜잭션을 제출할 제3자 에이전트 및/또는 매입 프로세서를 사용한다. 상기 발행자는 상기 트랜잭션 핸들러에게 상기 지불을 포워딩하며 상기 트랜잭션 핸들러는 상기 지불을 상기 매입자에게 포워딩하여 상기 트랜잭션에 대하여 상기 상인에 지불한다. 이 구현에서, 상기 제3자 에이전트는 에이전트 고유 식별자 및 비밀 코드를 채택한다. 상기 에이전트 고유 식별자 및 상기 비밀 코드를 사용하여 상기 제3자 에이전트에 의해 에이전트 고유 계정 결과가 유도된다. 이와 다른 대안으로, 상기 매입 프로세서는, 상기 매입자와 연관된 은행 식별 번호를 사용할 후원관계(sponsorship)가 없는 제3자 에이전트 각각에 관한 허가 요청 내에 예약된 에이전트 고유 계정 결과(reserved agent unique account result)를 배치시킬 수 있다.
다양한 구현들에서, 신뢰 에이전트 프로그램(trusted agent program; TAP)은 제3자 에이전트들 및 그 제3자 에이전트(들)에 의해 사용되고 있는 BIN들을 가진 매입자들을 시스템적으로 식별할 수 있다. 다른 구현들은 주어진 매입용 BIN에 대하여 매입 프로세서를 통해 트랜잭션을 제출하는 제3자 에이전트의 등록을 유효성확인(validating)하는데, 여기서 상기 제3자 에이전트는 상기 BIN을 인가하는 매입자에 의해 트랜잭션 핸들러에 등록된다. 에이전트 등록은 정보 보안 프로그램을 준수하는지에 관한 유효성확인을 필요로 할 수 있다. 또 다른 구현들은 미등록 에이전트에 의해 제출되고 있는 트랜잭션들에 관한 상인을 식별하는데, 여기에서 상기 트랜잭션 핸들러는 월간 리포트로 매입자들에게 이 정보를 제공하며, 매입자들은 그 BIN(들)을 사용하는 에이전트를 식별하는데 리포트들을 사용한다. 다른 구현들은, 매입 프로세서들이 매입자에게 할당되었던 BIN들을 사용하는 제3자 에이전트들에 관한 주기적 리스트들을 매입자들에게 제공할 것을 요구하도록, 지불 처리 시스템의 운영 규정들 및 비즈니스 규칙들을 시행한다. 또 다른 구현들은 전술한 기술들을 사용하여 매입자, 매입 프로세서, 제3자 에이전트 및 상인 간의 관계를 유효성확인할 수 있다.
본 발명의 구현들은 아래에 기재되어 있는 상세한 설명을 도면들과 함께 해석할 때 더 명확해질 것이며, 그 도면들에서 동일한 요소들은 동일한 참조 번호들을 가진다.
도 1은 도 2 내지 도 8에 해당하는 구현들이 실행될 수 있는 바람직한 지불 처리 시스템의 블록 다이어그램을 예시하고;
도 2a 내지 도 2c는, 함께 이해되어질 때, 도 1의 지불 처리 시스템 내에서 행해지는 바람직한 방법의 일 구현의 흐름도를 나타내고 있고;
도 3은 바람직한 신뢰 에이전트 프로그램에서의 바람직한 에이전트 셋업(setup)의 일 구현에 관한 도식적인 흐름도이고;
도 4는 바람직한 신뢰 에이전트 프로그램 트랜잭션 흐름의 일 구현에 관한 도식적인 흐름도이고;
도 5는 바람직한 신뢰 에이전트 프로그램을 위한 바람직한 리포트의 일 구현에 관한 도식적인 뷰이고;
도 6은 에이전트 고유 계정 결과(AUAR)의 계산 및 구성을 위한 일 구현에 관한 도식적인 그림이고;
도 7은 도 6의 AUAR에 대한 바람직한 테스트 벡터들을 예시하는 일 구현의 표이며; 그리고
도 8은, 휴대용 소비자 트랜잭션 기기 예를 들면 신용 카드의 자기 띠(magnetic stripe) 상의 트랙 1 및 트랙 2에 대한 바람직한 레이아웃을 예시하며 그리고 주 계정 번호(PAN)의 배치를 식별하는 일 구현의 도식적인 도면이다.
지불 처리 네트워크에서의 트랜잭션 핸들러는 트랜잭션에 대한 허가 요청을 제3자 에이전트로부터 수신할 수 있다. 이 경우에, 그 트랜잭션은 상인과 소비자에 의해 행해지며, 여기서 그 트랜잭션은 발행자에 의해 그 소비자에게 발행된 계정 상에서 행해진다. 바람직한 지불 처리 시스템(100)이 도 1에 묘사되어 있는데 그것은, 발행자(104); 트랜잭션 핸들러(106); 매입자(108); 상인(110); 및 소비자(102)를 포함한다. 매입자(108)와 발행자(104), 그리고 다른 개체(entity)들은 트랜잭션 핸들러(106)를 통해 통신할 수 있다. 상인(110)은 매입자(108), 트랜잭션 핸들러(106) 또는 발행자(104)와 통신할 수 있는 적어도 하나의 POS(Point of Service) 단말을 활용할 수 있다. 따라서, POS 단말은 지불 처리 시스템(100)과 통신을 한다.
하나의 구현에서, 트랜잭션 핸들러에 의해 제3자 에이전트로부터 수신된 허가 요청은, 매입자에게 인가된 은행 식별 번호(BIN) 및 제3자 에이전트에 대한 에이전트 고유 계정 결과(AUAR)를 포함한다. 트랜잭션 핸들러는 AUAR이 유효한지 무효한지 여부에 관한 결과를 결정한다. 주 계정 번호(PAN) 및 에이전트 식별자가 그 AUAR로부터 유도될 수 있는 경우 AUAR은 유효한데, 여기서 그 PAN은 상인과의 트랜잭션을 행하는 소비자의 계정에 대응되며 그리고 그 에이전트 식별자는 다른 상기 제3자 에이전트들에 각각 대응되는 다른 에이전트 식별자들과 대비하여 지불 처리 네트워크 내에서 고유하다. 그 PAN이 상인과의 트랜잭션을 행하는 소비자의 계정에 대응하지 않을 때 또는 그 에이전트 식별자가 다른 제3자 에이전트들에 각각 대응되는 다른 에이전트 식별자들에 대비하여 지불 처리 네트워크 내에서 고유성을 결여할 때 AUAR은 무효하다. 트랜잭션 핸들러는, BIN을 사용할 수 있도록 등록되어 있는 상태를 가지는 각각의 에이전트 식별자를 포함하는 다수의 에이전트 식별자들을 포함하고 있는 등록 세트 내에 그 에이전트 식별자를 배치함으로써 제3자 에이전트가 그 BIN을 사용할 수 있도록 등록되어 있는지 여부에 관한 결과를 결정한다. 그 에이전트 식별자는 그것이 에이전트 식별자들의 세트 내에 있는 경우 유효한 것으로 그리고 그 세트 내에 있지 않은 경우 무효한 것으로 결정될 수 있다. 제3자 에이전트의 아이디 및 BIN은, AUAR이 무효할 때, 제3자 에이전트가 BIN을 사용할 수 있도록 등록되어 있지 않을 때, 그리고 그 에이전트 식별자가 무효할 때 매입자로의 전송에서 발송될 것이다. 제3자 에이전트가 BIN을 사용할 수 있도록 등록되어 있지 않을 때, 매입자는 통지받을 것이다. 상기 전송은 또한 BIN을 사용할 수 있도록 등록되어 있는 상태를 가진 각각의 에이전트 식별자를 포함하는 에이전트 식별자들과 상인을 연관시키기 위한 요청을 포함할 것이다.
본 발명의 구현들은 신뢰 에이전트 프로그램(TAP)을 포함한다. TAP 구현들에서, 사기행위 감소 대책은 지불 시스템에 참여하는 모든 제3자 에이전트들을 식별하는 것에 초점을 맞춘다. TAP는, 지불 시스템에서 참여자들을 식별하며 그리고 이들 개체들에게 캘리포니아 샌프란시스코에 위치한 Visa 사의 카드소지자 정보 보안 프로그램(Cardholder Information Security Program; CISP)과 같은 정보 보안 프로그램에 따르는지를 유효성확인할 것을 요청함으로써 지불에 관련된 위험성(risk)을 줄일 수 있다. TAP는 적어도 부분적으로는 모든 에이전트들(114)에게 각각의 허가 요청을 고유하게 식별할 것을 요청함으로써 이 목표를 달성한다.
적어도 하나의 구현에서의 TAP들의 이점들 중 몇 가지는 다음을 포함한다: 지불 시스템(100)에서 동작하는 모든 에이전트들(114)을 식별함; 매입자들(108)이 그것의 BIN들을 사용하고 있는 에이전트들(114)을 식별하며 그리고 이들 BIN들을 사용하고 있는 모든 에이전트들(114)이 그 매입자(108)에 의해 등록되어 있음을 보장하도록 도움; 매입 프로세서들(116) 및 에이전트들(114)이 운영 규정들을 따르도록 도움 - 매입 프로세서들(116)이 에이전트들(114)에 의한 매입자 BIN들의 사용에 관하여 그들의 매입자 클라이언트들 및 트랜잭션 핸들러(106)에게 주기적인 리포트들을 제공할 것을 요구함; CISP 준수에 참여하며 그 준수를 유효성확인하는 에이전트들(114)에 경쟁적 이익을 제공; CISP를 준수하는 등록 에이전트들(114)이 트랜잭션 핸들러(106)의 준수 제공자(compliant providers) 리스트에 있으며 그 리스트는 또한 웹사이트 액세스를 통해 입수가능함; TAP에 참여하는 매입 프로세서들(116)에게 경쟁적 이익을 제공함, 매입자들(108)은 자신(116)에 연결된 모든 에이전트들(114)을 식별할 수 있는 매입 프로세서들(116)과 비즈니스하기를 원함; 모든 참여자들이 카드소지자 정보 보안 프로그램(CISP)의 준수를 유효성확인하게 함으로써 지불 처리 시스템을 보호함 - 여기서 CISP 유효성확인은 정보유출의 위험성을 상당히 감소시킴; 지불 처리 시스템(100)에 참여하는 에이전트들에서의 정보유출 발생률을 낮춤으로써 - 정보유출 위험성을 낮추는 것은 모든 참여자들에 있어서 매출액(volume) 및 수익성(profitability)을 증대시켜 주는 결과를 낳음 - 카드소지자(102)의 신뢰를 증대시킴; TAP를 통해 식별된 모든 에이전트들(114)이 완전히 등록되어질 것을 그리고 CISP에 따를 것을 요구함으로써, 등록된 그리고 CISP에 따르는 에이전트들(114)에 대한 "필드를 레벨링(leveling)함".
TAP는 시스템적으로 미등록 에이전트를 식별하여 그 에이전트에 의해 사용되고 있는 BIN들을 가진 매입자들에게 그 미등록 에이전트를 보고함으로써 이러한 목표들을 달성한다. 매입자들은 그들의 BIN들을 사용하는 미등록 에이전트들을 식별하는 월간 리포트를 수신한다.
이 개시에 있어서, 매입자는, 상인과 가맹계약(sign)하거나 현금 지급 식으로 카드소지자에게 통화를 지급하며, 그리고 지불 시스템 프로세스 교환 내에 결과적인 트랜잭션 영수증을 직접적 또는 간접적으로 입력하는 멤버이다. 매입자는, 물품 또는 서비스에 관한 지불에 관하여 지불 시스템 휴대용 기기를 받아주도록(accept) 상인들과 계약하는 지불 시스템 금용 기관이다. 매입자는 또한, 이러한 상인이 발생시킨 트랜잭션들을 처리하도록 에이전트들 및 매입 프로세서들과 계약할 수 있다. 매입자는, 에이전트 고유 계정 결과(AUAR) 명세사항(specification)에 따르지 않는 트랜잭션들을 갖거나 또는 그 매입자가 등록하지 않은 매입자의 BIN들을 사용하는 에이전트들을 식별하는 월간 TAP 리포트들을 트랜잭션 핸들러로부터 수신한다. 프로세서(매입 프로세서)는, 상인들 및 멤버들을 위해 허가 서비스, 청산(clearing) 서비스 또는 결제(settlement) 서비스를 제공하는, 지불 처리 시스템(100)의 멤버, 또는 트랜잭션 핸들러, 또는 어떤 멤버의 에이전트로서 활동하는 것으로서 트랜잭션 핸들러가 승인한 비멤버(nonmember)이다. 프로세서들은 지불 처리 시스템(100)의 일부인 네트워크에 직접적으로 연결되어 있다.
예시로서, 소비자(102)가 이를테면 컴퓨터 단말 또는 휴대용 소비자 기기(112)의 사용을 통해 상인(110)에게 계정의 계정 번호를 제시함으로써 트랜잭션을 시작하여 물품 또는 서비스에 대한 교역을 개시한다. 소비자(102)는 개인 또는 법인체일 수 있다. 소비자(102)는, 이를테면 법인 계정에 대한 액세스권을 가진 법인체의 직원과 같이 계정에 대한 액세스권을 가진 사람 또는 이를테면 계정의 공동 계정 소지자와 같이 발행자(104)에 의해 발행된 계정의 계정 소지자일 수 있다. 휴대용 소비자 기기(112)는 지불 카드(payment card), 선물 카드(gift card), 스마트카드(smartcard), 스마트 미디어, 급여 카드(payroll card), 헬스 케어 카드(health care card), 손목대(wrist band), 계정 정보를 포함하고 있는 기계 판독가능 매체(machine readable medium), 또는 슈퍼마켓 할인 카드나 ExxonMobil 사에서 상업적으로 입수가능한 SPEEDPASS®와 같은 키체인 기기(keychain device), 셀룰러 전화기, PDA(personal digital assistant), 페이저(pager), 보안 카드, 컴퓨터, 액세스 카드, 무선 단말, 또는 트랜스폰더(transponder)를 포함할 수 있다. 휴대용 소비자 기기(112)는 계정 소지자의 이름이나 계정 번호와 같은 정보를 저장하기 위한 휘발성 또는 비휘발성 메모리를 포함할 수 있다.
상인(110)은 POS 단말과 같은 수용 포인트(acceptance point) 기기를 사용하여, 휴대용 소비자 기기(112)로부터 계정예 대한 표시자(indicator)(예: 계정의 계정 번호)와 같은 계정 정보를 획득한다. 휴대용 소비자 기기(112)는, 무선 주파수(radio frequency), 자기장 인식 시스템을 사용하는 비접촉식 시스템, 또는 자기띠 판독기와 같은 접촉식 시스템과 같은 임의의 적합한 전기적, 자기적, 또는 광학적 인터페이싱 시스템을 포함하는 메커니즘을 사용하여 POS 단말과 인터페이싱할 수 있다. POS 단말은 휴대용 소비자 기기(112)의 발행자(104)에게로 트랜잭션 허가 요청을 발송한다. 이와 다르게, 또는 이와 조합하여, 휴대용 소비자 기기(112)는 발행자(104), 트랜잭션 핸들러(106) 또는 매입자(108)와 통신할 수 있다.
발행자(104)는 트랜잭션 핸들러(106)를 통해 트랜잭션을 허가할 수 있다. 허가는 발행자(104) 또는 발행자(104)를 대신하는 트랜잭션 핸들러(106)가 발행자(104)의 지시들과 관련하여 이를테면 비즈니스 규칙들의 사용을 통하여 트랜잭션을 허가하는 것을 포함한다. 비즈니스 규칙들은 트랜잭션 핸들러(106), 소비자(102), 상인(110), 매입자(108), 발행자(104), 금융 기관, 또는 이것들의 조합들로부터의 지시들이나 가이드라인들을 포함할 수 있다. 트랜잭션 핸들러(106)는 허가된 트랜잭션들의 로그(log) 또는 히스토리(history)를 보존할 수 있다. 일단 승인되면, 상인(110)은 그 허가를 기록할 수 있고 소비자(102)에게 물품이나 서비스를 받을 수 있게 해 준다.
상인(110)은, 하루의 끝과 같이 어떤 간격의 주기로, 허가된 트랜잭션들의 리스트를 지불 처리 시스템(100)의 매입자(108) 또는 다른 콤포넌트들에게 제출할 수 있다. 트랜잭션 핸들러(106)는 제출된 허가 트랜잭션 리스트를, 허가된 트랜잭션들에 관한 자기 자신의 로그와, 비교할 수 있다. 만약 일치되는 것이 발견되면, 트랜잭션 핸들러(106)는 트랜잭션 금액 허가 요청(authorization transaction amount request)들을 해당 매입자(108)로부터 각 트랜잭션에 관여된 해당 발행자(104)에게로 라우팅할 수 있다. 일단 매입자(108)가 발행자(104)로부터 허가된 트랜잭션 금액의 지불을 수신하면, 그것은 수수료와 같은 어떤 트랜잭션 비용을 빼고 그 지불을 상인(110)에게 포워딩할 수 있다. 만약 그 트랜잭션이 직불 카드 또는 선불 카드를 수반한다면, 매입자(108)는 상인(110)에 지불하기에 앞서 초기 지불을 기다리지 않도록 선택할 수 있다.
전술한 프로세스에서 간헐적인 단계들이 있을 수도 있고, 이들 단계들 중 일부는 동시에 일어날 수도 있다. 예를 들어, 매입자(108)는 청산 및 결제 프로세스를 개시할 수 있고, 이는 트랜잭션 금액에 대하여 매입자(108)에 지불하는 결과를 낳을 수 있다. 매입자(108)는 트랜잭션 핸들러(106)로부터 트랜잭션이 청산되고 결제되어야 함을 요청할 수 있다. 청산은 발행자(104)와 매입자(108) 간의 금융 정보의 교환을 포함하며 결제는 예금(funds)의 교환을 포함한다.
트랜잭션 핸들러(106)는 트랜잭션의 청산 및 결제와 관련한 서비스들을 제공할 수 있다. 예를 들어, 신용(credit)을 수반하는 트랜잭션의 청산 및 결제는 트랜잭션의 허가 후에 일어날 수 있다. 트랜잭션의 결제는, 결제 은행과 같은 결제 기관(settlement house)으로의 예치(deposit)를 위해 발행자(104)가 발행자 청산 은행과 같은 청산기관(clearinghouse)으로부터 트랜잭션 결제 금액을 인출하는 것을 포함한다. 트랜잭션 핸들러(106)는 트랜잭션 결제 금액을 매입자 청산 은행으로 예치한다. 해당 매입자(108)는 그 매입자 청산 은행으로부터 그 트랜잭션 결제 금액을 인출한다. 전형적으로, 발행자(104)는 발행자 청산 은행을 선택하고, 트랜잭션 핸들러(106)는 결제 은행을 선택하며, 그리고 매입자는 청산 은행을 선택한다. 트랜잭션이 직불(debit)을 포함할 때, 청산은 허가 프로세스 동안 일어날 수 있다. 따라서, 전형적인 트랜잭션은 청산 및 결제를 위한 트랜잭션 처리를 요청하고, 허가하며, 그리고 이행하는 다양한 개체들을 수반한다.
부가하여, 지불 처리 시스템(100)은, 매입자(108)로의 제출을 위해 상인(100)에서 행해지는 구매들을 통합정리하는 것과 같이 상인(110)을 위해 부가 가치 서비스들을 제공할 수 있는 제3자 에이전트들(114) 및/또는 프로세서들(116)을 포함할 수 있다.
개시된 구현들에 따른 신뢰 에이전트 프로그램(TAP)은, 지불 시스템에 참여하는 모든 제3자 에이전트들을 식별하는데에 초점이 맞추어진 사기행위 감소 대책을 포함한다. TAP는, 그 지불 시스템에서 참여자들을 식별하여 이들 개체들에게 정보 보안 프로그램 - 예컨대 미국 캘리포니아 샌프란시스코의 Visa 사의 카드소지자 정보 보안 프로그램(CISP) - 의 준수를 유효성확인할 것을 요구함으로써 지불에 관련된 위험성을 감소시킬 수 있다. TAP는 모든 제3자 에이전트들(114)에게 각각의 허가 요청을 고유하게 식별할 것을 요구함으로써 적어도 부분적으로 이 목표를 달성한다.
적어도 하나의 구현에서의 TAP들의 이점들 중 몇 가지는 다음을 포함한다: 지불 시스템(100)에서 동작하는 모든 에이전트들(114)을 식별함; 매입자들(108)이 그것의 BIN들을 사용하고 있는 에이전트들(114)을 식별하며 그리고 이들 BIN들을 사용하고 있는 모든 에이전트들(114)이 그 매입자(108)에 의해 등록되어 있음을 보장하도록 도움; 매입 프로세서들(116)이 에이전트들(114)에 의한 매입자 BIN들의 사용에 관하여 그들의 매입자 클라이언트들 및 트랜잭션 핸들러(106)에게 주기적인 리포트들을 제공할 것을 요구함으로써 매입 프로세서들(116) 및 에이전트들(114)이 운영 규정들을 따르도록 도움; 에이전트들(114)의 CISP 준수를 유효성확인함으로써 참여하는 에이전트들(114)에 경쟁적 이익을 제공; CISP를 준수하는 등록 에이전트들(114)이 트랜잭션 핸들러(106)의 준수 제공자 리스트 내에 있으며 그 리스트는 또한 웹사이트 액세스를 통해 입수가능하게 됨; 매입자들(108)이 자신(116)에 연결된 모든 에이전트들(114)을 식별할 수 있는 매입 프로세서들(116)과 비즈니스하길 더 선호한다는 점에서 TAP에 참여하는 매입 프로세서들(116)에게 경쟁적 이익을 제공함; 모든 참여자들이 CISP와 같은 정보 보안 프로그램의 준수를 유효성확인하게 함으로써 지불 처리 시스템을 보호함 - 여기서 이러한 유효성확인은 정보유출의 위험성을 상당히 감소시킴; 지불 처리 시스템(100)에 참여하는 에이전트들에서의 정보유출 발생률을 낮춤으로써 - 정보유출 위험성을 낮추는 것은 모든 참여자들에 있어서 매출액 및 수익성을 증대시켜 주는 결과를 낳음 - 카드소지자(102)의 신뢰를 증대시킴; TAP를 통해 식별된 모든 에이전트들(114)이 완전히 등록되어지며 정보 보안 프로그램(즉, CISP)에 따를 것을 요구함으로써 등록된 그리고 정보 보안 프로그램(즉, CISP)에 따르는 에이전트들(114)에 대한 "필드를 레벨링(leveling)함".
TAP는 시스템적으로 미등록 에이전트를 식별하여 그 에이전트에 의해 사용되고 있는 BIN들을 가진 매입자들에게 그 미등록 에이전트를 보고함으로써 전술한 목표들을 달성한다. 매입자들은 그들의 BIN들을 사용하는 미등록 에이전트들을 식별하는 월간 리포트를 수신한다.
이 상세한 설명에서 사용되는 것으로서, 매입자는, 상인과 가맹계약하거나 현금 지급 식으로 카드소지자에게 통화를 지급하며, 그리고 지불 시스템 프로세스 교환 내에 결과적인 트랜잭션 영수증을 직접적 또는 간접적으로 입력하는 멤버이다. 매입자는, 물품 또는 서비스에 관한 지불에 관하여 지불 시스템 휴대용 기기를 받아주도록 상인들과 계약하는 지불 시스템 금용 기관이다. 매입자는 또한, 이러한 상인이 발생시킨 트랜잭션들을 처리하도록 에이전트들 및 매입 프로세서들과 계약할 수 있다. 매입자는, 에이전트 고유 계정 결과(AUAR) 명세사항에 따르지 않는 트랜잭션들을 갖거나 또는 그 매입자가 등록하지 않은 매입자의 BIN들을 사용하는 에이전트들을 식별하는 월간 TAP 리포트들을 트랜잭션 핸들러로부터 수신한다. 프로세서(매입 프로세서)는, 상인들 및 멤버들을 위해 허가 서비스, 청산 서비스 또는 결제 서비스를 제공하는, 지불 처리 시스템(100)의 멤버, 또는 트랜잭션 핸들러, 또는 어떤 멤버의 에이전트로서 활동하는 것으로서 트랜잭션 핸들러가 승인한 비멤버이다. 프로세서들은 지불 처리 시스템(100)의 일부인 네트워크에 직접적으로 연결되어 있다.
다음 유형의 프로세서들이 바람직하다: 허가 프로세서, 청산 프로세서, 오프쇼어 프로세서(offshore processor), 및 중요 시스템 사용자. 그러나, 이 리스트는 한정적이지 않으며 다른 유형의 프로세서들이 있을 수 있다. 본 개시내용에서는 특히 허가 활동을 행하는 매입 프로세서들을 다룬다.
에이전트는, 지불 처리 시스템(100)의 한 멤버에 의해 관여되어져서 지불 처리 시스템(100)과 관련하여 그 멤버를 대신하여 활동하거나 서비스를 제공하는 멤버 또는 비멤버로서, 프로세서 및 어떤 독립 판매 조직(independent sales organization)을 포함하는 어떤 계약자(contractor), 또는 제3자 서비스이다. 에이전트는, 트랜잭션 핸들러/네트워크에 직접 연결되어 있지는 않지만 트랜잭션 핸들러로의 전송을 위해 매입 프로세서에게로 트랜잭션을 전달하는 카드 프로세서를 포함한다. 에이전트는 제3자 서비서(third party servicer; TPS) 및 상인 서비서(merchant servicer; MS) 양자 모두를 포함한다. 본 개시내용에 있어서, TPS 및 MS 양자 모두는 에이전트로 불릴 것이다.
본 발명의 구현은 매입 프로세서에 의해 에이전트 고유 계정 결과(AUAR)로 채워진 데이터 필드를 제공하기 위해 향상된 허가 요청 메시지를 제공한다. 프로세서에게 허가 트랜잭션들을 전달하는 모든 에이전트들은 모든 허가 요청들에서 에이전트 고유 계정 결과(AUAR)를 제공할 것이 요구된다. 매입 프로세서는 허가 요청이 에이전트로부터 수신될 때 AUAR로써 특정 필드를 채운다. AUAR은 각각의 허가 요청에 있어서 에이전트에 의해 구성되는 12-바이트 필드일 수 있다. AUAR은 다음을 연접(concatenating)함으로써 구성될 수 있다:
1개의 숫자(digit)로 된 길이 바이트;
트랜잭션 핸들러에 의해 각 에이전트에 할당된 에이전트 고유 식별자(Agent Unique Identifier)로 불리는 5개의 숫자로 된 고유 식별자.
(도식적으로 도 6 상에서 134로 표시된) HMAC-SHA1으로 불리는 암호화 알고리즘(cryptographic algorithm)의 결과치에서의 최하위(least significant) 6 바이트(48 바이너리 비트). HMAC-SHA1은, 비밀 키 또는 코드와 함께 암호화 해쉬 함수(cryptographic hash function)를 사용하여 계산되는 메시지 인증 코드(message authentication code; MAC) 타입인 암호화 HMAC(keyed-Hash Message Authetication Code)이다. HMAC-SHA1은 메시지의 진정성(authenticity) 및 데이터 무결성(data integrity) 양자 모두를 동시에 검증하는데 사용될 수 있다. MD5나 SHA-1과 같은 어떠한 반복적인(iterative) 암호화 해쉬 함수라도 HMAC의 계산에 사용될 수 있으며, 이에 따라 결과적인 MAC 알고리즘은 HMAC-MD5 또는 HMAC-SHA1 (또한 HMAC-SHA-1으로도 불림)으로 칭할 수 있다. HMAC의 암호화 강도(cryptographic strength)에 관한 적어도 하나의 대책은 기저의 해쉬 함수의 암호화 강도, 키의 크기 및 품질(quality), 그리고 해쉬 출력 길이의 크기(비트)에 의존한다.
에이전트들은 HMAC-SHA1 계산을 구현하기 위해 코드에 대하여 공개적으로 입수가능한 소스들을 활용하도록 장려된다. AUAR, 그것의 구조 및 그것의 계산에 관한 설명이 아래에서 더 상세하게 기술되어 있다.
월말에, 트랜잭션 핸들러는 트랜잭션에서의 몇몇 팩터(factor)들을 유효성확인함으로써 각각의 허가 요청을 유효성확인한다. 팩터들의 유효성확인은 다음을 포함할 수 있다:
에이전트 고유 식별자를 유효성확인;
AUAR을 유효성확인;
에이전트가 매입자의 BIN(들)을 사용할 수 있도록 등록되어 있는지를 유효성확인.
유효성확인에 실패한 트랜잭션들은 요청에서 사용되었던 BIN을 가진 매입자에게 보고된다. TAP의 주기적 리포트가 매입자 또는 매입자의 지정자(designate)에게 발송된다. 만약 에이전트가 허가 요청 내에 AUAR을 공급하지 않으면, 매입 프로세서가 그 허가 요청 내에 예약된 값을 배치시켜야 할 것이다. 트랜잭션 핸들러(106)는 이 예약된 값을 해석하여 매입자에게 미지의 에이전트가 그 매입자의 상인과 비즈니스하고 있음을 통지할 수 있다. 이러한 경우들은 매입자에게 발송되는 주기적인 트랜잭션 핸들러 리포트에서 보고된다.
매입 프로세서는 상인과 대립되는 에이전트에 의해 그 매입 프로세서에게 허가 요청이 발송되는 때를 결정할 수 있는 능력을 가지는 것이 바람직하다. TAP는 허가 트랜잭션을 처리하는 모든 에이전트들이 TAP에 참여할 수 있도록 설계되었다. 허가 요청들은 하나보다 많은 수의 에이전트에 의해 처리될 수 있다. TAP는 허가 요청을 처리하는 각 에이전트가 AUAR을 제공할 수 있는 능력을 가진다.
TAP의 구현들은 트랜잭션 핸들러 프로세서들에 직접 연결된 에이전트들만이 참여하여야 함을 요구할 수 있다. TAP의 다른 구현들은 트랜잭션 핸들러/네트워크에 전달되어야 하는 잠재적 AUAR들의 개수를 확대시킨다. 다수의 AUAR들의 사용은 TAP의 구현 단계들 후에 시작될 수 있다.
프로세서들 및 에이전트들은 TAP의 잠재적 영향력을 알게 될 수 있다. 허가 요청들은 다수의 AUAR들을 포함하고 있을 수 있다. 트랜잭션 핸들러에 의해 요구되는 경우, 에이전트들은 다른 에이전트들로부터 AUAR들을 수신하고 있을 수 있으며 그리고 이것들을 허가 요청과 함께 전송할 것이 요구될 수도 있다. 프로세서들은 또한 단일 허가 요청에 대하여 다수의 AUAR들을 전송할 수 있도록 준비되어야 한다.
바람직한 TAP 구현
TAP는 에이전트가 트랜잭션 핸들러에 의해 에이전트에 제공된 데이터 및 트랜잭션 그 자체에 고유한 데이터에 기초하여 계산된 값을 제공하게 함으로써 운영될 수 있다. 이제 도 2a 내지 도 2c를 참조하여, TAP에 관한 하나의 바람직한 구현이 어떻게 동작되는지에 관한 논의를 할 것이다. 단계(S100)에서, 레지스트리가 설립되는데 그 레지스트리는 자신 내의 에이전트들에 대하여 적어도 하나의 보안 대책 요구사항을 가진다. 단계(S110)에서 어떤 에이전트가 보안 대책(들)에 따를 때, 단계(S115)는 그 레지스트리 내에 신뢰 에이전트를 기재하며 단계(S120)는 트랜잭션 핸들러가 각각의 등록된 에이전트에게 에이전트 고유 식별자(Agent Unique Identifier; AUI) 및 비밀 코드(즉, 숫자 코드)를 할당하게 한다. 단계(S130)에서, 에이전트는, 트랜잭션에 관한 주 계정 번호와 함께 AUI 및 비밀 코드 양자 모두를 사용하여, HMAC-SHA1 알고리즘이나 실질적으로 HMAC-SHA1 알고리즘인 알고리즘을 통해 에이전트 고유 계정 결과(AUAR)를 계산한다.
단계(S140)에서, 에이전트는 매입 프로세서에게 발송되는 모든 허가 요청 메시지들에서 AUAR을 전송한다. 단계(S150)에서, 매입 프로세서는, 에이전트에 의해 그 매입 프로세서에게 발송되었던, 트랜잭션 핸들러에게 발송되는 모든 허가 요청 메시지들에 AUAR을 포함시킬 것이 요구된다. 트랜잭션 핸들러는 나중에 월례적으로 처리하기 위해 허가 요청을 저장한다. 단계(S160)에서, AUAR은 전형적으로 발행자에게로 보내지지 않으며 또한 보유되어 그 요청하는 매입 프로세서에게로 되돌려지지도 않는다. 단계(170)에서, 트랜잭션 핸들러는 저장된 허가 요청들을 주기적으로(매월 또는 다른 간격으로) 사용하여 매입자들을 위한 리포트들을 생성하는데 그 리포트들은, (S180) 매입자 BIN들을 사용하는 모든 매입 프로세서들에 관하여 그 매입 프로세서가 사용할 수 있도록 후원되지 않음 (즉, 매입자가 그 매입 프로세서를 선정하지 않았음)을, 그리고/또는 (S190) 매입자의 BIN들을 사용하는 모든 에이전트들에 관하여 그것들이 사용할 수 있도록 등록되어 있지 않음 (즉, 매입자가 그 에이전트를 등록하지 않았음)을 보여준다.
만약 그 리포트들이 미후원된 매입 프로세서들이나 미등록된 에이전트들을 표시하고 있지 않으면, 그때는 단계들(S200, S210) 각각에서 어떠한 추가적인 활동도 요구되지 않는다. 그렇지 않으면, 어느 매입자에 의해서도 등록되지 않은 에이전트들에게 트랜잭션 핸들러에 의하여 에이전트 고유 식별자나 비밀 코드 어느 것도 제공되지 않았던 것이다. 매입 프로세서는 에이전트가 AUAR을 포함하지 않은 허가 요청을 제출하였음을 나타내는 예약된 AUAR을 제공받는다 (S220). 단계(S230)에서, 매입 프로세서는 에이전트가 AUAR을 공급하지 않을 때 트랜잭션 핸들러가 정의한 예약된 AUAR을 허가 요청 내에 배치시킨다.
트랜잭션 핸들러는 단계(S240)에서 매입자에게 매입 프로세서들 및 에이전트들에 의한 자신의 BIN들의 비허가된 사용에 관하여 월간으로 통지한다. 매입자는 또한 (S260) 매입 프로세서를 후원하는 것 그리고/또는 에이전트를 등록하는 것, 또는 (S270) 상인을 등록된 에이전트에게로 이동시키는 것 중 어느 하나를 선택(S250)하는 것을 필요로 한다.
TAP 동작
하나의 구현에서, TAP는 다음의 두 단계들로 동작한다: 1) 에이전트가 매입자에 의해 트랜잭션 핸들러에 등록됨 (아래의 TAP 에이전트 셋 업을 참조), 및 2) TAP이 작용하여 지불 처리 시스템(100)에 참여하는 에이전트들을 식별하여서 매입자에게 그 매입자에 의해 등록되어 있지 않으면서 그 매입자의 BIN들을 사용하는 에이전트들에 관하여 알린다 (아래의 TAP 트랜잭션 흐름을 참조).
TAP 에이전트 셋 업
이제 도 3을 참조하기로 하는데, 매입자는 자신의 BIN들을 에이전트가 사용하고 있음을 알아차린다. 그 매입자는 그 에이전트를 등록하지 않았다. 매입자는 에이전트로부터 듀 딜리전스(due diligence) 패킷을 요청한다 (단계 S300). 에이전트 등록은 카드소지자 정보 보안 프로그램(CISP)의 준수에 관한 유효성확인을 요구한다. 매입자는 듀 딜리전스를 행하며 그리고 트랜잭션 핸들러에게 제출되는 에이전트 등록 패킷(단계 S310)을 조립한다. 에이전트 등록을 받아들이는 경우, 트랜잭션 핸들러는 지금 등록된 에이전트에게 에이전트 고유 식별자 및 비밀 코드를 할당한다. 단계(S320)에서 에이전트 고유 식별자 및 비밀 코드가 에이전트에 배포된다. 에이전트는 암호키(encryption key)와 같은 방식으로 비밀 코드를 보안유지할 것이 요구된다 (에이전트는 이러한 값들을 사용하여, 모든 허가 요청 메시지들에 관하여 포함되어 있는 에이전트 고유 계정 결과(AUAR)를 계산함). 단계(S330)에서, 에이전트가 사용하는 모든 매입자 BIN들이 에이전트 고유 식별자 및 비밀 코드와 연관된다. 이 데이터는 트랜잭션 핸들러 네트워크에서 TAP 데이터 스토어 내에 삽입된다.
TAP 트랜잭션 흐름
이제 도 4를 참조하면, 단계(S400)에서 상인은 등록된 에이전트에게로 허가 요청을 발송한다. 등록된 에이전트는 AUAR을 계산하여 AUAR을 단계(S410)에서 매입 프로세서에게 발송되는 허가 요청 메시지 내에 삽입한다. 단계(S420)에서 매입 프로세서는 새로운 VIP 허가 요청 메시지 필드를 그 AUAR로 채운다. 단계(S430)에서 트랜잭션 핸들러는 허가 요청을 저장하며; 그리고 단계(S440)에서 트랜잭션 핸들러는, BIN(들)을 사용하는 에이전트(들)가 사용할 수 있게 등록되어 있지 않는다는 것을 보고하는 그 에이전트(들)에 관한 월간 리포트들을 생산한다. 트랜잭션 핸들러는 또한, 매입자에 의해 후원되지 않아 매입자의 BIN들을 사용하도록 허가되지 않은 매입 프로세서들을 식별한다. TAP 리포트들이 매입자 또는 매입자의 지정자에게 제공된다. 매입자들은, a) 그 에이전트를 등록하거나 또는 그 상인의 비즈니스를 그 에이전트로부터 떨어지게 이동시키는 것 중 어느 하나를 수행하여야 하거나; 또는 b) 그 매입 프로세서를 후원하거나 또는 그 상인을 그 매입 프로세서로부터 이동시키는 것 중 어느 하나를 수행하여야 한다.
매입자 구현
신뢰 에이전트 프로그램(TAP)은 매입자들에게 매입자의 BIN들을 사용하는 트랜잭션 핸들러의 네트워크에 트랜잭션들을 제출하는 미등록 에이전트들(제3자 서비서들 및 상인 서비서들 포함)에 관하여 알려준다. 비허가된 트랜잭션 핸들러의 네트워크 액세스는 지불 처리 시스템(100)의 보안을 손상시키며 사기행위로부터의 위험에 그 트랜잭션 핸들러를 노출시킨다. 비록 매입자들이 그들의 BIN들 하에 제출된 모든 트랜잭션들에 대하여 재정적으로 책임을 지지만, 그들은, 매입자의 상인들이 에이전트를 고용하고 그 매입자에게 알리지 않기 때문에, 상인-에이전트 합의관계에 관하여 종종 인지하고 있지 않기도 한다.
TAP는 매입 에이전트들을 통해 트랜잭션 핸들러에게 제출된 트랜잭션들을 모니터링하여 BIN들의 비허가된 사용을 매입자들에게 보고함으로써 매입자의 위험성을 크게 감소시킨다. 매입자들의 BIN들을 사용하는 에이전트들의 인식은 매입자들이 자신의 상인들 및 에이전트들을 관리할 수 있는 새로운 도구를 제공한다.
계획적으로, TAP 보고는 매입자들에게 월간으로 제공될 수 있다. 이러한 리포트에 관한 하나의 구현에 관련하여 도 5를 참조하기로 한다. TAP는, 적어도, a) 자신을 등록하여 놓은 매입자가 없는 경우에도 그것의 BIN들을 사용하는 에이전트들을 식별하는 것, b) 매입자의 BIN들을 사용하는 에이전트를 고용하는 상인(들)을 규정하는 것, c) 매입자에게 그것의 BIN(들)을 사용하는 모든 매입 프로세서들에 관하여 알리는 것을 통해, 매입자가 자신의 비즈니스를 관리할 수 있도록 도와준다.
TAP 리포트(118)(예를 들어 도 5를 참조)는 상인들 및 상인 트랜잭션들을 처리하는 에이전트들을 말해주며 그리고 트랜잭션 핸들러의 네트워크에 그 트랜잭션들을 제출한 매입 프로세서에 관한 언급사항을 포함한다.
매입자의 책임
TAP 리포트(118)(즉, 도 5를 참조)는, 매입자들이 상인을 에이전트와 연관시키며 그리고 트랜잭션 핸들러의 네트워크에 허가 요청을 제출한 매입 프로세서를 식별할 수 있게 해 주는 정보를 그 매입자들에게 제공한다. 정렬 시퀀스(sort sequence)의 일 구현은 다음과 같다: 멤버 (멤버명), 매입처 ID (BIN), 프로세서, 에이전트 ID (제3자), 상인, 이유; 페이지 나누기 포함: 멤버(멤버명).
도 5에서, 리포트 필드 라벨들에 대한 설명들은 다음과 같다: 비즈니스 ID(BUSINESS ID ) - 기업(business)에 할당된 고유 식별 번호; 멤버( MEMBER ) - 멤버 기관의 이름; 매입처 ID ( ACQR ID ) - 트랜잭션의 매입자로서 활동하는 금융 기관을 식별하는데 사용되는 매입 기관 식별 코드. 이것은 매입자의 코드 또는 매입자를 대신하여 활동하는 에이전트의 코드일 수 있음; 상태( STATUS ) - 해당 BIN이 할당된 것인지, 예약된 것인지, 또는 리콜(recall)된 것인지를 표시함; 프로세서( PCR ) - 매입자를 대신하여 활동하는 프로세서의 코드 및 이름; 에이전트 ID ( AGENT ID ) - 트랜잭션 핸들러에게 POS 트랜잭션들을 제출하는 에이전트들을 식별하는데 사용되는 코드 (에이전트 고유 ID); 상인( MERCHANT ) - 카드를 받는 자의 이름 (상인명); 이유( REASON ) - 이 그룹의 트랜잭션들이 TAP 준수 테스트들을 통과하지 못한 이유; 트랜잭션 카운트( TRANSACTION COUNT ) - 동일 행의 다른 값들에 의해 고유하게 식별되는 세트에 대한 트랜잭션들의 개수.
TAP 리포트는, 주기적으로 - 예를 들어 매월 초에 월간으로 (또는 다른 간격으로, 또는 요청에 따라) 이전 달에서 발생한 트랜잭션들에 대하여 - 생성된다. TAP 리포트 상의 모든 기재사항들은 매입자 측의 행동을 요구한다. 그 리포트 상의 각 라인은 허가 요청에서 트랜잭션 핸들러에게 제출된 것과 같은 상인명(Merchant Name)에 특정된(specific) 것이며 그리고 트랜잭션 카운트들은 단지 이전 달 동안의 그 매입자(Acquirer) - 에이전트(Agent) - 상인명(Merchant Name)에 관한 것이다.
매입자는 그 월간 리포트를 검토하여 그 매입자에 의해 등록되지 않았던 자신의 BIN들을 사용하는 에이전트들을 식별한다. TAP 리포트의 이유(REASON) 열은 5개의 가능한 상태들을 가진다: 1) 제3자 ID 없음(NO THIRD PARTY ID) - 허가 요청이 에이전트로부터 왔지만 그 에이전트는 AUAR을 제공하지 않았음을 매입 프로세서가 알 때 할당됨. 매입 프로세서는 트랜잭션 핸들러에 의해 제공되는 디폴트 값을 그 허가 요청에 채울 것임. 2) 미등록(UNREGISTERED) - AUAR은 유효하지만 매입자 BIN이 그 에이전트에 대한 등록된 매입자 BIN들의 리스트 상에 존재하지 않을 때 할당됨. 3) 무효 ID(ID INVALID) - AUAR이 유효하지 않지만 매입자 BIN이 그 에이전트에 대한 등록된 매입자 BIN들의 리스트 상에 존재할 때 할당됨. 4) 미등록 & 무효 ID (UNREGISTERED & ID INVALID) - AUAR이 존재하지만 유효하지 않으며 그리고 매입자 BIN이 그 에이전트에 대한 등록된 매입자 BIN들의 리스트 상에 존재하지 않을 때 할당됨. 5) ID 미정의(ID NOT DEFINED) - 에이전트 고유 식별자(AUI)(AUAR의 부분)가 유효하지 않을 때 할당됨.
매입자는 TAP 리포트 상에 표시된 상태에 기초하여 행동을 취할 수 있다. 취해지는 행동은 에이전트를 등록시키는 것 또는 상인을 등록 에이전트로 이동시키는 것일 수 있다. 매입자는 또한 TAP 리포트에서 특정된 매입 프로세서가 그 매입자에 의해 선정된 것인지를 유효성확인하여야 한다. 만약 매입자가 트랜잭션을 처리한 매입 프로세서를 지금 선정하여야 한다면, 그 매입자는 트랜잭션 핸들러에 근거사항(exhibit)을 제출할 수 있다. 트랜잭션의 매입 프로세서의 이름은 리포트의 프로세서(PCR) 열에서 발견된다.
매입 프로세서 구현
트랜잭션 핸들러의 네트워크에의 비허가된 액세스는 지불 처리 시스템(100)의 보안을 손상시키며 지불 처리 시스템(100)의 멤버를 사기행위로부터의 위험성에 노출시킨다. 비록 매입자들이 자신의 BIN들 하에 제출된 모든 트랜잭션들에 대하여 재정적으로 책임을 지지만, 그들은, 상인들이 그들의 매입자에게 에이전트와의 관계에 관하여 알려주지 않기 때문에, 상인-에이전트 합의관계에 관하여 종종 인지하고 있지 않기도 한다. 다수의 매입자들은 상인 트랜잭션들의 처리를 아웃소싱(outsourcing)한다. 그 트랜잭션들이 매입자를 거치치 않기 때문에, 그 매입자는 자신의 BIN들을 사용하는 모든 에이전트들을 인지하지 못할 수도 있다.
TAP는, 매입 프로세서가 에이전트들과 그것의 관계를 관리하기 위한 그리고 매입 프로세서가 지불 처리 시스템(100)에 대한 운영 규정들 및 다른 비즈니스 규칙들에 따르는 것을 돕기 위한 관리 도구를 매입 프로세서에 제공한다. TAP는 매입 에이전트들을 통해 지불 처리 시스템(100)에 제출된 트랜잭션들을 모니터링함으로써 매입자의 위험성을 감소시키며 그 경우 BIN들의 비허가된 사용을 매입자들에게 보고한다. 미등록된 에이전트들이 식별되어 매입자의 등록 및 트랜잭션 핸들러의 위험성 분석을 위해 기록되어진다.
매입 프로세서 책임
이제 도 6을 참조하기로 한다:
1. 매입자 시스템과 통신하는 모든 에이전트들을 식별할 수 있는 능력을 개발하는 것. 매입 프로세서들은 에이전트에 의해 매입 프로세서에 전송된 허가 요청들 및 상인으로부터 직접 온 허가 요청들을 구별할 수 있어야 한다. 지불 처리 시스템(100) 허가 요청 메시지들은 허가 요청의 소스에 따라 적절하게 포맷될 수 있다: 즉, 에이전트로부터 온 것들은 AUAR(120)을 담고 있어야 하며 (도 6), 상인으로부터 온 것들은 그것을 담고 있지 않아야 한다. 상인들은 에이전트 고유 계정 결과(AUAR)를 제공할 수 있게 허락되지 않는다. AUAR은 직접 상인으로부터 매입 프로세서에게 전송된 허가 요청들에 존재하지 않는다.
2. 에이전트 고유 계정 결과(AUAR)를 포함하도록 에이전트로부터의 허가 요청 메시지 포맷을 강화시키는 것. 매입 프로세서들은 에이전트들이 허가 요청들 내에서 12 바이트 AUAR을 전송하도록 그들 전유의 허가 요청 메시지 포맷들을 허용할 수 있다.
3. 강화된 허가 포맷을 각 에이전트가 준수함을 보증하는 것(certify). 매입 프로세서들은 전형적으로 모든 에이전트들에게 그들의 메시지 포맷의 준수를 보증할 것을 요구한다. 일단 매입 프로세서가 AUAR을 밝히기 위한 그들의 허가 요청 포맷을 강화시켰다면, 그 매입 프로세서는 허가 요청들을 전송하는 모든 에이전트들을 보증하여야 한다.
4. 리포트 필드 AUAR에 대한 지원을 발전시키는 것. 각각의 매입 프로세서는 트랜잭션 시스템 리포트 내 필드를 지원하여야 한다. 허가 요청이 에이전트에 의해 매입 프로세서에게 전송되면, 그 매입 프로세서는 허가 요청 메시지들 내 필드를 채워야 한다. 이 필드는 에이전트 고유 계정 결과(AUAR)로 부른다. AUAR은 3개의 서브-필드들로 이루어진 12 바이트 필드이다. 에이전트에 의해 전달된 처음 두 서브-필드들의 데이터 포맷(즉, ASCⅡ, BCD 등)은 매입 프로세서가 선택할 수 있다. 매입 프로세서는 에이전트에 의해 제공된 세 번째 서브-필드에서의 값을 변경해서는 안될 것이다.
서브-필드1(122): 길이 바이트. 이것은 TAP의 본 구현에 있어서 1로 세팅된다.
서브-필드2(124): 에이전트의 5 바이트 에이전트 고유 식별자(AUI). 이 값은 트랜잭션 핸들러에 의해 에이전트에 공급되며 그리고 모든 허가 요청들 내에 포함되어야 한다.
서브-필드3(126): 에이전트 고유 계정 결과(AUAR) 계산의 결과치로부터의 바이너리 데이터의 최하위 48 비트(6 바이트). 이 데이터는 에이전트의 HMAC-SHA1 계산의 결과로부터 변하지 않은 채 유지된다. 그것은 정확히 에이전트에 의해 매입 프로세서에게 제공되는 것과 같이 트랜잭션 핸들러에게 전달된다.
트랜잭션 프로세서로의 요청을 구성할 때, 매입 프로세서는 표 1에 따라 AUAR의 포맷을 갖추어야 하며 그리고 그 AUAR을 리포트 내의 필드 내에 배치시켜야 한다.
표 1. 에이전트 고유 계정 결과(AUAR)
필드 번호(Field Number)
필드명(Field Name)
에이전트 고유 계정 결과(Agent Unique Account Result)
포맷(Format)
변수 길이(Variable length)
1 바이트 바이너리
+5 바이트의 EBCDIC
+6 바이트(48 비트) 바이너리 비트 스트링;
총 12 바이트
값(Value)
에이전트-특정(agent-specific) 데이터 및 해쉬용 알고리즘의 결과로 이루어진 문자 스트링
기술사항(Description)
그 메시지가 에이전트로부터 발송되었음을 나타낼 고유 식별자.
5. 트랜잭션 핸들러를 통해 트랜잭션 필드의 사용을 보증하는 것. 매입자들 및 그들의 매입 프로세서들은 신뢰 에이전트 프로그램(TAP)을 지원하여야 한다. 매입 프로세서들은 트랜잭션 핸들러를 통해 그 트랜잭션 필드를 사용하는 것을 보증하여야 한다. 트랜잭션 핸들러는 프로세서들에게 그들의 TAP 구현을 테스트할 기회를 제공하기 위해 지불 처리 시스템 인증 관리 시스템(certification management system; CMS) 내에 TAP를 인스톨하였다.
트랜잭션 필드는 발행자 프로세서에게 발송되거나 허가 응답으로 반환되지 않는다. 그 리포트 내 필드는 트랜잭션 핸들러에 의해 오프라인으로 유효성확인될 수 있다. 등록을 필요로 하는 에이전트들을 상술하는 월간 TAP 리포트들이 매입자 또는 매입자의 지정자에게 발송된다.
6. 트랜잭션이 에이전트로부터 왔지만 어떠한 AUAR도 공급되지 않았을 때 트랜잭션 핸들러 허가 요청 내에 디폴트 AUAR을 삽입하는 것.
만약 매입 프로세서가 에이전트로부터 허가 요청을 수신하지만 AUAR이 포함되어 있지 않으면, 그 매입 프로세서는, 지불 처리 시스템(100) 제출을 위해, 트랜잭션 핸들러가 공급하는 디폴트 AUAR을 사용하여야 한다.
서브-필드: 바이너리 1로 세팅
서브-필드2: EBCDIC 99999로 세팅
서브-필드3: 16진수 ffffffffffff로 세팅됨
7. AUAR 필드를 채우는 것
매입 프로세서들은 에이전트들로부터 AUAR을 수신하는 능력을 개발할 것이 요구된다. 에이전트들로부터의 모든 허가 요청 메시지들은 AUAR을 구비할 수 있다. 프로세서들은 에이전트가 계산한 AUAR을 수신하여 이 값을 리포트의 한 필드 내에 배치시키는 능력을 가질 수 있다. 만약 매입 프로세서가 상인으로부터 직접 요청들을 수신하면, 그 AUAR 필드는 트랜잭션 핸들러에게로 발송되는 허가 요청 내에 존재하여서는 안 된다.
8. 에이전트들에의 도움을 테스트하는 것
에이전트들은 그것들의 TAP 구현을 테스트하는 동안 도움을 요구할 수도 있다. HMAC-SHA-1 계산의 유효성확인을 위한 테스트 벡터들의 집합이 도 7에 도시되어 있다. VCMS가 이용가능하기 때문에, 프로세서들의 그리고 에이전트들의 구현의 유효성확인이 이용가능하다.
에이전트 구현
에이전트 역할
에이전트들은 지불 처리 시스템(100)의 보안에 결정적인 역할을 한다. 에이전트는 그 에이전트, 매입자 및 상인 클라이언트들의 이익을 보호하기 위해 CISP에 따라야 한다. 에이전트 등록이 CISP 준수의 유효성확인을 요구하기 때문에, 트랜잭션 핸들러(106)는 지불 처리 시스템(100) 내의 모든 참여자들이 그들 자신을 식별하며 그리고 에이전트에 의해 사용되는 BIN들을 가진 모든 매입자들에 의해 등록될 것을 요구할 수 있다.
TAP는 모든 에이전트들이 지불 시스템에 등록 개체들로서 참여할 기회를 제공한다. 등록 및 CISP 준수는 매입자들, 매입 프로세서들 및 상인들이 에이전트의 안정성 및 건전성을 유효성확인하기 위한 방법이 되었다. CISP를 준수하는 에이전트들은 그들의 성장이 그들의 CISP 상태에 기인하여 증가하였음을 알아차릴 수 있다. 모든 CISP 준수 서비스 제공자들은 CISP 준수 서비스 제공자들(CISP Compliant Service Providers)의 리스트 상에 기재될 수 있다.
TAP는 에이전트들이 지불 처리 시스템(100)에서 그들 자신을 식별하며 그들 자신을 포지셔닝하는 방식을 제공한다. 참여하지 않는 에이전트들이 TAP에 의해 인식될 수 있으며 그리고 사용되어지고 있는 BIN들을 가진 매입자들에 의해 접촉될 수 있다. 신뢰 에이전트가 되는 것은 다음을 요구할 수 있다: a) 적어도 하나의 매입자에 의해 트랜잭션 핸들러에 등록되는 것; b) 카드소지자 정보 보안 프로그램(CISP)의 준수를 유효성확인하는 것; 및 c) 신뢰 에이전트 프로그램(TAP)에 참여하는 것.
에이전트 책임
에이전트 책임은 다음을 포함하지만, 이에 제한되지 않는다.
1. 매입자들로부터의 등록 요청에 응답하는 것. 월간 기반으로, 트랜잭션 핸들러(106)는 매입자들에게 TAP 리포트들을 공급한다. TAP 리포트는 아직 해당 매입자에 의해 등록되지 않은 에이전트들을 기술한다. 그 매입자는 이러한 에이전트들을 등록한다. 등록 프로세스는 매입자가 에이전트에 관하여 듀 딜리전스를 행할 것을 요구한다. 에이전트를 등록할 것을 필요로 하는 매입자들은 그 에이전트로부터 듀 딜리전스 패키지들을 요청한다. 적어도 다음 두 가지 경우들이 있다: a) 에이전트가 다른 매입자(들)에 의해 등록되는 경우. 이 경우에, 그 에이전트는 다른 매입자들에게 제공되어진 듀 딜리전스 패키지를 가져야 할 것임; 및 b) 그 에이전트가 어떤 지불 처리 시스템 멤버에 의해 이제 등록되어야 하는 경우. 이 경우에, 매입자는 듀 딜리전스에 대한 요구사항들을 그 에이전트에 제공할 것이다. 그 에이전트는 그 듀 딜리전스 패키지를 조립하여 그 패키지를 그 요청하는 매입자에게 제공한다.
등록은 신뢰 에이전트가 되는데 있어 첫 번째 단계이다. 모든 등록 에이전트들은 카드소지자 정보 보안 프로그램(CISP) 준수를 유효성확인하여야 한다.
2. 일 개인이 에이전트의 트랜잭션 핸들러 연락자(liaison)임을 지정하는 것. 일단 에이전트가 매입자에게 듀 딜리전스 패키지를 제공하였고, 그 매입자가 그 패키지를 검토하여 승인하였다면, 그 매입자는 그 에이전트를 트랜잭션 핸들러에 등록한다. 그 트랜잭션 핸들러는 지정된 연락자의 연락처 정보를 위해 그 에이전츠와 접촉한다. 현재 등록되어 있는 것들을 포함하여 모든 에이전트들은 트랜잭션 핸들러(106)에게 연락자 연락처 정보를 제공할 것이 요구된다.
3. 비밀 코드(즉, 숫자 코드) 및 에이전트 고유 식별자를 수신하며 그리고 두 데이터 조각들을 보호하는 것. 일단 에이전트가 적어도 하나의 매입자에 의해 등록되면, 트랜잭션 핸들러는 보안 이메일 기능을 통해 에이전트의 지정된 트랜잭션 핸들러의 연락처로 다음의 데이터를 이메일로 전송할 수 있다:
에이전트 고유 식별자 - 이 값은 5자리 숫자들일 수 있다. 이 값은 에이전트의 비즈니스 식별자(Business Identifier; BID)의 하위 차수(lower order) 5자리 숫자들이다.
비밀 코드(숫자 코드) - 이 값은 16개의 문자들일 수 있고 대소문자 및 숫자들을 포함할 수 있다. 그것은 트랜잭션 핸들러에 의해 랜덤하게 생성되며 그리고 그 에이전트에 대해 고유하다.
상기 데이터는 요청이 발송되어 향하는 매입 프로세서에 무관하게 모든 허가 요청들에서 사용될 수 있다. 각각의 에이전트는 그 에이전트에 고유한 이 데이터를 보호할 것이 예측된다. 비밀 코드는 암호키가 보호될 것과 같이 보호되어야 할 것이다.
트랜잭션 핸들러(106)는 이 데이터를 필요한 모든 현재 등록된 에이전트들에게 제공할 수 있다. 새로운 에이전트가 등록될 때, 그 에이전트는 양 데이터 조각들을 제공받을 수 있다. 일단 에이전트가 양 데이터 조각들을 수신하였고, 그 에이전트가 매입 프로세서(들)를 통해 보증하였다면, 그 에이전트는 지불 처리 시스템(100) 프로세서(들)에게 AUAR을 전송하기 시작할 수 있다.
4. 각각의 허가 요청에서 사용되는 주 계정 번호를 분리해내는 능력을 개발하고 테스트하는 것. 에이전트들은 각 허가 요청에 대하여 주 계정 번호(PAN)를 분리해낼 것이 요구될 수 있다. 카드 존재형 트랜잭션들의 경우에, PAN은 그 허가 요청과 관련하여 발송된 전체 트랙으로부터 파싱(parsing)될 필요가 있을 수 있다. 카드 비존재형 허가 요청들에서(예: 메일오더(Mail Order)-전화오더(Telephone Order), 전자상거래(e-commerce)), 트랙 데이터가 존재하지 않을 수 있다. PAN은 상인의 허가 요청의 전유 포맷으로부터 추출되는 것이 필요할 수 있다. 도 8은 트랙 1 및 트랙 2에 대한 레이아웃을 포함하며 PAN의 배치를 식별한다. 에이전트들은 PAN을 분리해내어 그것을 AUAR의 계산에서 사용하는 능력을 개발하는 것이 필요할 수 있다.
5. 에이전트 고유 식별자(AUI), 주 계정 번호(PAN) 및 비밀 코드를 활용하여 AUAR을 계산하는 것. 에이전트 고유 계정 결과(AUAR)의 계산은 다음의 데이터를 요구한다:
주 계정 번호(130)
에이전트 고유 식별자(124)
비밀 코드(128).
AUAR의 계산에 관한 설명은 아래에서 주어진다. 그 설명은 또한 HMAC-SHA-1 계산 및 요구되는 필드의 구성을 유효성확인하는 능력을 에이전트들에게 제공하는 테스트 벡터들의 집합을 포함하고 있다.
PAN의 배치를 식별하는 두 트랙 1 및 트랙 2의 레이아웃이 도 8에 주어져 있고 아래에서 설명된다. 그 도면은 16 자리 숫자 PAN의 포지션을 보여준다. 13, 16 및 19 자리 숫자들의 PAN들을 수신하는 것이 가능하지만, 대다수는 16 자리 숫자들일 수 있다.
12 바이트 AUAR은 3개의 서브-필드들로 이루어질 수 있다:
서브-필드1: 길이 바이트. 이것은 항상 또는 전형적으로 1로 세팅될 수 있다.
서브-필드2: 에이전트의 5 바이트 에이전트 고유 식별자(AUI). 이 값은 트랜잭션 핸들러(106)에 의해 에이전트에 공급되며 그리고 모든 허가 요청들 내에 포함된다.
서브-필드3: HMAC-SHA-1 계산의 결과치로부터의 바이너리 데이터의 최하위 48 비트(6바이트). 이 데이터는 HMAC-SHA1 계산의 결과로부터 변하지 않은 채 유지되어야 한다.
AUAR의 서브-필드3은 HMAC-SHA1 알고리즘을 사용한 계산 값이다. 서브-필드3의 계산에 관한 설명이 아래에 있다.
HMAC-SHA1 코드에 대한 소스들은 앞에서 설명되었으며 테스트 벡터들은 에이전트의 AUAR 구현을 유효성확인하는데 사용되어야 한다. 입수가능 코드를 사용하여 AUAR의 서브-필드3을 계산하는 것을 강력하게 추천한다. 입수가능 HMAC-SHA-1 코드의 소스들은 앞에서 설명되었다.
6. 자신이 연결되어 있는 모든 매입 프로세서들을 통해 보증하는 것. 에이전트들은 매입 프로세서들에게 허가 요청들을 전달한다. 매입 프로세서가 그들의 허가 요청의 전유 포맷을 강화시켜야 할 수도 있기 때문에, 에이전트는 그들이 연결되어지는 모든 매입 프로세서들을 통해 보증하여야 한다. 에이전트들은 그들의 전유 메시지 포맷의 강화에 관한 세부사항들과 관련하여 그리고 보증(certification)에 대한 지시사항들과 관련하여 자신들이 연결되어 있는 매입 프로세서들과 접촉할 수 있다.
7. AUAR을 모든 허가 요청 메시지들 내에 삽입하는 것. 에이전트가 매입 프로세서(들)를 통해 성공적으로 인증하였고 AUAR의 계산을 유효성확인하였을 때, 그 에이전트는 TAP에 참여할 준비가 된다.
에이전트들은 에이전트에 의해 처리되는 각각의 허가 요청에 대하여 새로운 값을 매입 프로세서들에게 공급하여야 한다. 이 값은 에이전트 고유 계정 결과(AUAR)로 불린다. 그 AUAR은 매입 프로세서에 의해 현재 요구되는 필수 정보와 함께 그 매입 프로세서에게 포워딩된다. 그 매입 프로세서는 트랜잭션 핸들러(106)에게 그 허가 요청을 제출할 수 있다.
에이전트 고유 계정 결과( AUAR )의 구현
AUAR 설명
에이전트 고유 계정 결과(AUAR)는 각 허가 요청 트랜잭션에 대하여 고유한 값이다. AUAR은 에이전트에 의해 계산되며 트랜잭션 핸들러(106)에 의해 사용되어, 에이전트가 등록되어 있어 트랜잭션 핸들러(106)의 운영 규정들에 의해 요구되는 에이전트 의무를 수행하고 있음을 유효성확인할 수 있다. 에이전트에 의해 프로세서에게로 발송되는 각각의 허가 요청은 AUAR을 포함하여야 한다. 각각의 AUAR은 AUAR을 계산하는데 사용되는 알고리즘에 기초하여 고유할 수 있다. 트랜잭션 핸들러(106)는 AUAR을 유효성확인하여서 그 AUAR을 계산하여 발송하였던 에이전트가 상인의 매입자에 의해 등록된 것임을 보장할 수 있다.
AUAR은 12 바이트 길이이고 별개인 3개의 서브 필드들로 이루어진다:
1 - 길이 바이트
2 - 5 바이트 에이전트 고유 식별자
3 - HMAC-SHA1 계산의 결과치(132)로부터의 최하위 6 바이트(48 바이너리 비트). HMAC-SHA1을 계산하기 위한 코드는 아래에 기재된 공개 웹사이트들에서 입수가능하다.
그 에이전트는 매입 프로세서에 의해 특정된 포맷으로 매입 프로세서에게 AUAR을 전송할 수 있다. 그 에이전트는 AUAR에 대한 명세사항에 관하여 매입 프로세서를 통해 체크하여야 한다. 각 서브-필드가 아래에서 기술된다.
서브-필드1: 길이 바이트 - AUAR 내의 최상위 바이트(첫 번째 바이트)가 1로 세팅될 수 있다. 서브-필드2: 에이전트 고유 식별자 - AUAR의 2-6번째 바이트가 트랜잭션 핸들러(106)에 의해 에이전트에 제공되는 5개 문자의 에이전트 고유 식별자로 세팅되어야 한다. 서브-필드3: HMAC-SHA1 알고리즘의 결과치 - AUAR의 7-12번째 바이트가 HMAC-SHA1 알고리즘(134)의 결과치(132)의 최하위 48 비트(136)로 세팅되어야 한다. 이 서브-필드는 정확히 HMAC-SHA1 알고리즘에 의해 산출된 것과 같은 바이너리 포맷으로 매입 프로세서에게 발송되어야 한다. 매입 프로세서는 정확히 그 에이전트에 의해 제공된 것과 같은 이 서브-필드를 전송하여야 한다.
현재 구현에서, TAP을 위한 HMAC-SHA1은 2개의 ASCⅡ 입력들을 요구한다: 1) 멀티-바이트 데이터 값. 에이전트 고유 원 결과(Agent Unique Raw Result; AURR, 138)로 불리는 이 21개 문자 데이터 값은 각각의 허가 요청에 대하여 고유하며 다음 2개의 데이터 조각들로 이루어진다: a) 트랜잭션 핸들러(106)에 의해 에이전트에게 제공되는 5-문자의 에이전트 고유 식별자; b) 그 허가 요청에 대한 16자리 숫자 계정 번호. 상기 멀티-바이트 데이터 값은 5자리 숫자 에이전트 고유 식별자에 트랜잭션을 위한 16자리 숫자 계정 번호를 덧붙임으로써 조립된다. AURR(138) = {에이전트 고유 식별자 | 계정 번호}. 2) 멀티-바이트 키 값. 이 16개 문자 키 값은 비밀 코드로서 트랜잭션 핸들러(106)에 의해 각 에이전트에 제공된다. 각 에이전트는 트랜잭션 핸들러(106)로부터, 고유한, 랜덤하게 생성된 비밀 코드를 수신할 수 있다. 그 비밀 코드는 대소문자들 및 10진수 숫자들로 이루어져 있으며 그리고 트랜잭션 핸들러(106)에 의해 에이전트에 공급되는 정확한 형태로 사용되어야 한다.
HMAC-SHA-1의 출력은 메시지 인증 코드(MAC)이다. 도 6은 AUAR의 계산 및 구성을 예시하고 있다. 도 7은 HMAC-SHA1 알고리즘에 관한 입력들 및 예측되는 출력들을 가진 테스트 벡터들을 포함하고 있다. 에이전트들은 이들 입력들을 통해 그들 코드를 테스트하여, 산출시 그 알고리즘을 사용하기에 앞서 에이전트의 AUAR 구현이 정확한지를 유효성확인할 수 있다. 도 7에서 제공되는 테스트 케이스들에 부가하여, 공개적으로 입수가능한 추가적인 테스트 케이스들이 있다. 이러한 공개적으로 입수가능한 테스트 케이스들은 단지 HMAC-SHA1 계산의 기능을 유효성확인하기만 하고 완결된 AUAR을 계산하기 위한 데이터를 포함하지 않음을 유념하여야 할 것이다.
주 계정 번호의 위치 - 트랙 1 및 트랙 2
하나의 구현에서, 그리고 더 자세하게는 도 8을 참조하면, 주 계정 번호(PAN, 130)는 카드(112)의 자기띠의 트랙 1 및 트랙 2 양자 모두에 있다. 그 자기띠는 카드 제공 트랜잭션들에서 상인 소재지에서 판독될 수 있다. 에이전트들은 에이전트 고유 계정 결과(AUAR)의 계산에서의 사용을 위해 PAN을 추출할 수 있어야 한다. 도 8은 양 트랙들 모두에서의 PAN의 위치를 보여준다.
비록 PAN들이 가장 일반적으로는 16자리 숫자들이지만, 13, 15 및 19자리 숫자의 PAN들이 존재하며 그리고 HMAC-SHA-1 계산을 위해 적절히 구성되어야 한다. PAN은 항상 분리기호(separator, 140)가 뒤따를 수 있다.
각각의 PAN 길이는 바람직하게는 계산에 앞서 다음과 같이 구성될 것이다: 13자리 숫자 PAN - 최하위 3개 포지션들에 공백(space)들로 패딩(padding)하여 16개 문자들로 끝남; 15자리 숫자 PAN - 최하위 포지션에 공백들로 패딩하여 16개 문자들로 끝남; 16자리 숫자 PAN - 트랙으로부터 추출된 대로 사용, 모든 16자리 숫자들이 사용되어야 함; 19자리 숫자 PAN - 그 PAN의 고차 16자리 숫자들을 사용하며, 최하위 3자리 숫자들의 사용을 드롭함.
카드 비제공 트랜잭션들에 대하여 허가를 요청하는 클라이언트들을 서비스하는 에이전트들은, 상기에서 기술된 바와 같은 구성들을 사용하는 것이 필요할 수 있다.
본 발명의 구현들은 제어 로직의 형태, 모듈식 또는 집적식일 수 있고, 소프트웨어, 하드웨어 또는 이들 조합을 사용하는 것일 수 있음을 이해하여야 할 것이다. 본 출원에서 개시된 구현들과 관련하여 기재된 방법, 프로세스 또는 알고리즘의 단계들은 직접적으로 하드웨어로, 프로세서에 의해 실행되는 소프트웨어 모듈로, 또는 그 둘의 조합으로 구현될 수 있다.
방법 또는 프로세서 내의 다양한 단계들 및 활동들이 도시된 순서로 수행될 수도 있고, 또는 다른 순서로 수행될 수도 있다. 부가하여, 하나 이상의 프로세서 또는 방법 단계들이 생략될 수도 있고 또는 하나 이상의 프로세스 또는 방법 단계들이 그 방법들과 프로세스들에 부가될 수도 있다. 부가적인 단계, 블록 또는 활동은 그 방법들 및 프로세스들의 시작, 끝 또는 중간 존재 요소들에 부가될 수 있다. 본 출원에서 제공되는 개시 및 교시내용들에 기초하여, 관련 기술분야에서의 당업자는 다양한 구현들에 대한 다른 방식들 및/또는 방법들을 인식할 것이다.
본 출원에서 기재된 예시들 및 구현들은 단지 예시를 위한 것이라는 점 그리고 그 관점에 비추어 다양한 변형들이나 변화들이 관련 기술분야의 당업자에게 암시될 것이어서 아래 특허청구범위의 청구항들의 범위 및 본 출원의 사상 및 범위 내에 포함되어야 할 것임을 이해할 수 있다.

Claims (33)

  1. 지불 처리 네트워크(payment processing network)에서의 트랜잭션(transaction)을 위한 허가 요청(authorization request)을 제3자 에이전트로부터 수신하는 단계 - 상기 허가 요청은,
    매입자(acquirer)에게 인가된 은행 식별 번호(bank identification number; BIN), 및
    상기 제3자 에이전트에 대한 에이전트 고유 계정 결과(agent unique account result; AUAR)를 포함함;
    상기 AUAR로부터, 상인(merchant)과의 상기 트랜잭션을 행하는 소비자의 계정(account)에 대응되는 주 계정 번호(primary account number; PAN), 및 다른 상기 제3자 에이전트들에 각각 대응되는 다른 상기 에이전트 식별자들과 대비하여 상기 지불 처리 네트워크 내에서 고유한 에이전트 식별자를 유도해 냄으로써, 상기 AUAR이 유효하다는(valid) 결과, 또는
    상기 PAN이 상기 상인과의 상기 트랜잭션을 행하는 상기 소비자의 계정에 대응되지 않거나, 또는 상기 에이전트 식별자가 다른 상기 제3자 에이전트들에 각각 대응되는 다른 상기 에이전트 식별자들에 대비하여 상기 지불 처리 네트워크 내에서 고유하지 않다고 결정함으로써, 상기 AUAR이 무효(invalid)하다는 결과
    중에서 제1 결과를 결정하는 단계; 및
    복수의 상기 에이전트 식별자들 - 상기 에이전트 식별자들 각각은 상기 BIN을 사용할 수 있도록 등록되어 있는 상태를 가짐 - 을 포함하고 있는 등록 세트 내에 상기 에이전트 식별자를 배치시킴으로써 상기 제3자 에이전트가 상기 BIN을 사용할 수 있도록 등록되어 있는지 여부에 관한 제2 결과를 결정하는 단계를 포함하는 것을 특징으로 하는 방법.
  2. 제1항에 있어서,
    상기 방법은,
    상기 에이전트 식별자가 상기 에이전트 식별자들의 집합 내에 있다고 결정함으로써 상기 에이전트 식별자가 유효하다는 결과, 및
    상기 에이전트 식별자가 상기 에이전트 식별자들의 상기 집합 내에 존재하지 않는다고 결정함으로써 상기 에이전트 식별자가 무효하다는 결과
    중에서 제3 결과를 결정하는 단계를 더 포함하는 것을 특징으로 하는 방법.
  3. 제2항에 있어서,
    상기 방법은, 이벤트의 발생 시에 상기 매입자에게로 전달될 전송 - 상기 전송은 상기 BIN 및 상기 제3자 에이전트의 아이디를 포함함 - 을 제기하는 단계를 더 포함하며,
    상기 이벤트는,
    상기 AUAR이 무효하다는 제1 결과를 결정하는 것;
    상기 제3자 에이전트가 상기 BIN을 사용할 수 있도록 등록되어 있지 않다는 제2 결과를 결정하는 것; 및
    상기 에이전트 식별자가 무효하다는 제3 결과를 결정하는 것
    을 포함하는 그룹으로부터 선택되는 것을 특징으로 하는 방법.
  4. 제1항에 있어서,
    상기 제3자 에이전트가 상기 BIN을 사용할 수 있도록 등록되어 있지 않을 때, 상기 전송은 상기 제3자 에이전트가 상기 BIN을 사용할 수 있도록 등록되어 있지 않다는 정보를 더 포함하는 것을 특징으로 하는 방법.
  5. 제2항에 있어서,
    상기 방법은, 이벤트의 발생 시에 상기 매입자에게로 전달될 전송 - 상기 전송은 상기 상인의 아이디를 포함함 - 을 제기하는 단계를 더 포함하며,
    상기 이벤트는,
    상기 AUAR이 무효하다는 결과를 결정하는 것;
    상기 제3자 에이전트가 상기 BIN을 사용할 수 있도록 등록되어 있지 않다는 결과를 결정하는 것; 및
    상기 에이전트 식별자가 무효하다는 결과를 결정하는 것
    을 포함하는 그룹으로부터 서택되는 것을 특징으로 하는 방법.
  6. 제5항에 있어서,
    상기 트랜잭션은 복수의 상기 에이전트 식별자들 - 상기 에이전트 식별자들 각각은 상기 BIN을 사용할 수 있도록 등록되어 있는 상태를 가짐 -과 상기 상인을 연관시키기 위한 요청을 더 포함하는 것을 특징으로 하는 방법.
  7. 제1항에 있어서,
    상기 방법은, 상기 AUAR을 실질적으로 HMAC-SHA1 알고리즘으로부터 유도해내는 단계를 더 포함하는 것을 특징으로 하는 방법.
  8. 제1항에 있어서,
    상기 BIN을 사용할 수 있도록 등록되어 있는 상기 제3자 에이전트는 또한 데이터 보안 규격(data security standard)에 따르는 것을 특징으로 하는 방법.
  9. 제1항에 있어서,
    상기 지불 처리 네트워크는, 발행자(issuer)에 의해 하나의 상기 소비자에게 발행된 하나의 상기 계정 상에서 상기 트랜잭션을 행하는 하나의 상기 소비자와 하나의 상기 상인에 의해 특징지워지는 각 트랜잭션을 가진 복수의 상기 트랜잭션들을 처리하는 트랜잭션 핸들러(transaction hander)를 포함하며;
    하나의 상기 상인은 하나의 상기 제3자 에이전트에게 상기 트랜잭션을 제출하며, 하나의 상기 제3자 에이전트는 하나의 상기 매입자에 대하여 등록된 하나의 상기 BIN을 사용하여 상기 트랜잭션 핸들러에 의한 처리를 위해 상기 트랜잭션을 제출하며 - 상기 트랜잭션 핸들러는 상기 발행자에게 상기 트랜잭션에 대한 지불을 획득할 것을 요청함; 그리고
    상기 발행자는 상기 트랜잭션 핸들러에게 상기 트랜잭션에 대한 지불을 포워딩하며 상기 트랜잭션 핸들러는 상기 지불을 하나의 상기 제3자 에이전트에게 포워딩하여 상기 트랜잭션에 대하여 하나의 상기 상인에게 지불하는 것을 특징으로 하는 방법.
  10. 매입자에게 인가된 은행 식별 번호(BIN)를 사용하여 트랜잭션을 위한 허가 요청을 지불 처리 네트워크에 제출하는 제3자 에이전트를 식별하는 방법에 있어서, 상기 방법은,
    에이전트 고유 계정 결과(AUAR)를 반환시키기 위한 요청을 상기 제3자 에이전트에게 발송하는 단계;
    상기 제3자 에이전트로부터 상기 AUAR을 수신하는 단계;
    상기 AUAR로부터, 상인과의 상기 트랜잭션에 관여된 소비자의 계정에 대응되는 주 계정 번호(PAN) 및 상기 에이전트 식별자, 및 복수의 상기 에이전트 식별자들 - 각각이 다른 상기 에이전트 식별자들에 대비하여 고유하며 각각이 하나의 상기 제3자 에이전트와 연관됨 - 을 가진 레지스트리(registry) 내에 포함된 에이전트 식별자를 유도해 냄으로써, 상기 AUAR이 유효하다는 결과, 또는
    상기 PAN이 상기 상인과의 상기 트랜잭션을 행하는 상기 소비자의 계정에 대응되지 않거나, 또는 상기 에이전트 식별자가 상기 레지스트리 내에 포함되어 있지 않다고 결정함으로써, 상기 AUAR이 무효하다는 결과
    중에서 제1 결과를 결정하는 단계; 및
    상기 에이전트 식별자가 상기 레지스트리 내에 있다고 결정함으로써 상기 에이전트 식별자가 유효하다는 결과, 그리고 상기 에이전트 식별자가 상기 레지스트리 내에 있지 않다고 결정함으로써 상기 에이전트 식별자가 무효하다는 결과
    중에서 제2 결과를 결정하는 단계를 포함하는 것을 특징으로 하는 방법.
  11. 제10항에 있어서,
    상기 방법은,
    상기 에이전트 식별자가 상기 BIN을 사용할 수 있도록 등록되어 있는 상태를 가진다고 결정함으로써, 상기 제3자 에이전트가 상기 BIN을 사용할 수 있도록 등록되어 있다는 결과;
    상기 에이전트 식별자가 상기 레지스트리 내에 포함되어 있지 않거나, 또는 상기 에이전트 식별자가 상기 BIN을 사용할 수 있도록 등록되어 있는 상태를 가지지 않는다고 결정함으로써, 상기 제3자 에이전트가 상기 BIN을 사용할 수 있도록 등록되어 있지 않다는 결과
    중에서 제3 결과를 결정하는 단계를 더 포함하는 것을 특징으로 하는 방법.
  12. 제11항에 있어서,
    상기 방법은,
    이벤트의 발생 시에 상기 매입자에게로 전달될 전송 - 상기 전송은 상기 BIN 및 상기 제3자 에이전트의 아이디를 포함함 - 을 제기하는 단계를 더 포함하며,
    상기 이벤트는,
    상기 AUAR이 무효하다는 제1 결과를 결정하는 것;
    상기 에이전트 식별자가 무효하다는 제2 결과를 결정하는 것; 및
    상기 제3자 에이전트가 상기 BIN을 사용할 수 있도록 등록되어 있지 않다는 제3 결과를 결정하는 것
    을 포함하는 그룹 중에서 선택되는 것을 특징으로 하는 방법.
  13. 제12항에 있어서,
    상기 방법은, 통지를 주기적으로 발송하는 단계를 더 포함하는 것을 특징으로 하는 방법.
  14. 제12항에 있어서,
    상기 제3자 에이전트가 상기 BIN을 사용할 수 있도록 등록되어 있지 않을 때, 상기 전송은 상기 제3자 에이전트가 상기 BIN을 사용할 수 있도록 등록되어 있지 않다는 정보를 더 포함하는 것을 특징으로 하는 방법.
  15. 제12항에 있어서,
    상기 제3자 에이전트가 상기 BIN을 사용할 수 있도록 등록되어 있지 않을 때, 상기 전송은 상기 상인의 아이디를 더 포함하는 것을 특징으로 하는 방법.
  16. 제15항에 있어서,
    상기 전송은, 상기 BIN을 사용할 수 있도록 등록되어 있는 상태를 가진 하나의 상기 에이전트 식별자와 상기 상인을 연관시키기 위한 요청을 더 포함하는 것을 특징으로 하는 방법.
  17. 제10항에 있어서,
    상기 레지스트리에 포함되어 있는 복수의 상기 에이전트 식별자들은 각각, 데이터 보안 규격에 따르는 하나의 상기 제3자 에이전트와 연관되는 것을 특징으로 하는 방법.
  18. 제10항에 있어서,
    상기 방법은, 상기 AUAR을 실질적으로 HMAC-SHA1 알고리즘으로부터 유도해내는 단계를 더 포함하는 것을 특징으로 하는 방법.
  19. 제10항에 있어서,
    상기 지불 처리 네트워크는, 발행자에 의해 하나의 상기 소비자에게 발행된 하나의 상기 계정 상에서 상기 트랜잭션을 행하는 하나의 상기 소비자와 하나의 상기 상인에 의해 특징지워지는 각 트랜잭션을 가진 복수의 상기 트랜잭션들을 처리하는 트랜잭션 핸들러를 포함하며;
    하나의 상기 상인은 하나의 상기 제3자 에이전트에게 상기 트랜잭션을 제출하며, 하나의 상기 제3자 에이전트는 하나의 상기 매입자에 대하여 등록된 하나의 상기 BIN을 사용하여 상기 트랜잭션 핸들러에 의한 처리를 위해 상기 트랜잭션을 제출하며 - 상기 트랜잭션 핸들러는 상기 발행자에게 상기 트랜잭션에 대한 지불을 획득할 것을 요청함; 그리고
    상기 발행자는 상기 트랜잭션 핸들러에게 상기 트랜잭션에 대한 지불을 포워딩하며 상기 트랜잭션 핸들러는 상기 지불을 하나의 상기 제3자 에이전트에게 포워딩하여 상기 트랜잭션에 대하여 하나의 상기 상인에게 지불하는 것을 특징으로 하는 방법.
  20. 발행자가 소비자에게 발행하는 지불 기기에 의해 연관된 계정 상에서 트랜잭션에 관여하는 소비자 및 상인에 의해 특징지워지는 각 트랜잭션을 포함하는 복수의 트랜잭션들을 처리하는 트랜잭션 핸들러를 포함하는 지불 처리 네트워크 - 상기 상인은 제3자 에이전트에게 상기 트랜잭션을 제출하며, 상기 제3자 에이전트는 매입자에 대해 등록된 은행 식별 번호(BIN)를 사용하여 상기 트랜잭션 핸들러에 의한 처리를 위해 상기 트랜잭션을 제출하며 상기 트랜잭션 핸들러는 상기 발행자에게 상기 트랜잭션에 대한 지불을 획득할 것을 요청하며, 그리고 상기 발행자는 상기 트랜잭션 핸들러에게 상기 지불을 포워딩하며 상기 트랜잭션 핸들러는 상기 지불을 상기 제3자 에이전트에게 포워딩하여 상기 트랜잭션에 대하여 상기 상인에게 지불함 - 에서의 방법으로서, 상기 방법은,
    상기 복수의 트랜잭션들 각각에 관련하여 에이전트 고유 계정 결과(AUAR) - 상기 AUAR은 상기 제3자 에이전트에 의해 계산되는 넘버이거나, 또는 상기 제3자 에이전트가 상기 넘버를 계산하지 않는 경우에는 상기 AUAR은 예약 넘버(reserved number)임 - 를 전송시키기 위한 요청을 상기 트랜잭션 핸들러에게 발송하는 단계;
    상기 트랜잭션 핸들러로부터 상기 AUAR을 수신하는 단계;
    상기 AUAR로부터, 상인과의 트랜잭션에 관여된 소비자의 계정에 대응되는 주 계정 번호(PAN) 및 상기 에이전트 식별자, 및 복수의 상기 에이전트 식별자들 - 각각은 다른 상기 에이전트 식별자들에 대비하여 고유하며 각각은 하나의 상기 제3자 에이전트와 연관됨 - 을 가진 레지스트리에 포함된 에이전트 식별자를 유도해 냄으로써, 상기 AUAR이 유효하다는 결과, 그리고
    상기 AUAR이 상기 예약된 넘버이거나, 상기 PAN이 상기 상인과의 상기 트랜잭션을 행하는 상기 소비자의 계정에 대응되지 않거나, 또는 상기 에이전트 식별자가 상기 레지스트리 내에 포함되어 있지 않다고 결정함으로써, 상기 AUAR이 무효하다는 결과
    중에서 제1 결과를 결정하는 단계; 및
    상기 에이전트 식별자가 상기 레지스트리 내에 있다고 결정함으로써 상기 에이전트 식별자가 유효하다는 결과, 및 상기 에이전트 식별자가 상기 레지스트리 내에 있지 않다고 결정함으로써 상기 에이전트 식별자가 무효하다는 결과
    중에서 제2 결과를 결정하는 단계를 포함하는 것을 특징으로 하는 방법.
  21. 제20항에 있어서,
    상기 방법은,
    상기 에이전트 식별자가 상기 BIN을 사용할 수 있도록 등록되어 있는 상태를 가진다고 결정함으로써 상기 제3자 에이전트가 상기 BIN을 사용할 수 있도록 등록되어 있다는 결과; 및
    상기 에이전트 식별자가 상기 레지스트리 내에 포함되어 있지 않다거나 또는 상기 에이전트 식별자가 상기 BIN을 사용할 수 있도록 등록되어 있는 상태를 가지지 않는다고 결정함으로써 상기 제3자 에이전트가 상기 BIN을 사용할 수 있도록 등록되어 있지 않다는 결과
    중에서 제3 결과를 결정하는 단계를 더 포함하는 것을 특징으로 하는 방법.
  22. 제21항에 있어서,
    상기 방법은,
    이벤트의 발생 시에 상기 매입자에게 전달될 전송 - 상기 전송은 상기 BIN 및 상기 제3자 에이전트의 아이디를 포함함 - 을 제기하는 단계를 더 포함하고,
    상기 이벤트는,
    상기 AUAR이 무효하다는 제1 결과를 결정하는 것;
    상기 에이전트 식별자가 무효하다는 제2 결과를 결정하는 것; 및
    상기 제3자 에이전트가 상기 BIN을 사용할 수 있도록 등록되어 있지 않다는 제3 결과를 결정하는 것
    을 포함하는 그룹으로부터 선택되는 것을 특징으로 하는 방법.
  23. 제22항에 있어서,
    상기 방법은, 통지를 주기적으로 발송하는 단계를 더 포함하는 것을 특징으로 하는 방법.
  24. 제22항에 있어서,
    상기 제3자 에이전트가 상기 BIN을 사용할 수 있도록 등록되어 있지 않을 때, 상기 전송은 상기 제3자 에이전트가 상기 BIN을 사용할 수 있도록 등록되어 있지 않다는 정보를 더 포함하는 것을 특징으로 하는 방법.
  25. 제22항에 있어서,
    상기 제3자 에이전트가 상기 BIN을 사용할 수 있도록 등록되어 있지 않을 때, 상기 전송은,
    상기 상인의 아이디, 및
    상기 BIN을 사용할 수 있도록 등록되어 있는 상태를 가진 하나의 상기 에이전트 식별자와 상기 상인을 연관시키기 위한 요청
    을 더 포함하는 것을 특징으로 하는 방법.
  26. 제22항에 있어서,
    상기 방법은, 상기 AUAR을 실질적으로 HMAC-SHA1 알고리즘으로부터 유도해 내는 단계를 더 포함하는 것을 특징으로 하는 방법.
  27. 발행자가 소비자에게 발행한 계정 상에서 복수의 트랜잭션들 중 한 트랜잭션에 관여하는 소비자 및 상인에 의해 특징지워지는 각 트랜잭션을 포함하는 복수의 트랜잭션들을 처리하는 트랜잭션 핸들러를 포함하는 지불 처리 시스템 - 상기 상인은 상기 트랜잭션 핸들러에 의한 처리를 위해 매입자에게 상기 트랜잭션을 제출하며 상기 트랜잭션 핸들러는 상기 발행자에게 상기 소비자로부터 상기 트랜잭션에 대한 지불을 획득할 것을 요청하며, 그리고 상기 발행자는 상기 트랜잭션 핸들러에게 상기 지불을 포워딩하며 상기 트랜잭션 핸들러는 상기 지불을 상기 매입자에게 포워딩하여 상기 트랜잭션에 대하여 상기 상인에게 지불함 - 에서의 컴퓨터 구현 방법으로서, 상기 컴퓨터 구현 방법은,
    보안 대책(secure measure)에 따르는 제3자 에이전트들에 대한 레지스트리를 설립하는 단계;
    제3자 에이전트가 상기 보안 대책에 따를 때 상기 제3자 에이전트에게 에이전트 고유 식별자 및 비밀 코드를 할당하는 단계;
    상기 트랜잭션에 대한 주 계정 번호와 함께 상기 제3자 에이전트 고유 식별자 및 비밀 코드의 사용을 요구하는 단계;
    상기 에이전트 고유 식별자 및 상기 비밀 코드로부터 에이전트 고유 계정 결과를 식별하는 단계;
    상기 제3자 에이전트가 매입 프로세서에게 발송되는 허가 요청 메시지들에서 상기 에이전트 고유 계정 결과를 전송할 것을 요청하는 단계;
    상기 매입 프로세서로 하여금 상기 제3자 에이전트에 의해 상기 매입 프로세서에게 발송된 상기 허가 요청 메시지들 내에 상기 에이전트 고유 계정 결과를 포함시키도록 강제하는 단계;
    상기 허가 요청 메시지들을 저장하는 단계; 및
    상기 매입자와 연관된 은행 식별 번호들을 사용하는 모든 매입 프로세서들에 관하여 상기 매입자가 상기 매입 프로세서를 사용할 것으로 지정하지 않았음을, 그리고 상기 매입자의 은행 식별번호들을 사용하는 모든 에이전트들에 관하여 그 에이전트들이 상기 레지스트리에 등록되어 있지 않음을, 상기 매입자에게 주기적으로 보고하는 단계를 포함하는 것을 특징으로 하는 컴퓨터 구현 방법.
  28. 제27항에 있어서,
    상기 방법은, 에이전트가 에이전트 고유 계정 결과 없이 허가 요청을 제출하였음을 나타내는 예약된 에이전트 고유 계정 결과를 상기 매입 프로세서에게 제공하는 단계를 더 포함하는 것을 특징으로 하는 컴퓨터 구현 방법.
  29. 제28항에 있어서,
    상기 방법은, 상기 에이전트가 에이전트 고유 계정 결과를 공급하지 않을 때 상기 매입 프로세서에게 상기 허가 요청 내에 상기 예약된 에이전트 고유 계정 결과를 배치시키도록 요구하는 단계를 더 포함하는 것을 특징으로 하는 컴퓨터 구현 방법.
  30. 제27항에 있어서,
    상기 방법은, 주기적으로 매입 프로세서들 및 에이전트들에 의해 상기 매입자의 은행 식별 번호들의 비허가된 사용에 관하여 상기 매입자에게 통지하는 단계를 더 포함하는 것을 특징으로 하는 컴퓨터 구현 방법.
  31. 제27항에 있어서,
    상기 방법은, 상기 매입자로 하여금, a) 상기 매입 프로세서를 후원(sponsor)하며 상기 에이전트를 등록하는 것, 그리고 b) 상기 상인을 상기 레지스트리에서 등록 에이전트로 이동시키는 것 중 하나를 하게 하는 단계를 더 포함하는 것을 특징으로 하는 컴퓨터 구현 방법.
  32. 제27항에 있어서,
    상기 요구하는 단계는, HMAC-SHA1 알고리즘, 및 상기 에이전트 고유 식별자 및 상기 비밀 코드를 사용하여 상기 제3자 에이전트에 대한 에이전트 고유 계정 결과를 계산하는 것을 요구하는 것을 포함하는 것을 특징으로 하는 컴퓨터 구현 방법.
  33. 제27항에 있어서,
    상기 방법은, 적어도 일부는 컴퓨터에 의해 실행되는 명령들에 의해 수행되며, 상기 명령들은 컴퓨터 판독가능 매체에 속한 것임을 특징으로 하는 컴퓨터 구현 방법.
KR1020107023494A 2008-03-21 2009-03-19 지불 처리 시스템에서의 신뢰 에이전트 식별 KR20100135268A (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US12/052,927 US20090240627A1 (en) 2008-03-21 2008-03-21 Payment processing system trusted agent identification
US12/052,927 2008-03-21

Publications (1)

Publication Number Publication Date
KR20100135268A true KR20100135268A (ko) 2010-12-24

Family

ID=41089846

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020107023494A KR20100135268A (ko) 2008-03-21 2009-03-19 지불 처리 시스템에서의 신뢰 에이전트 식별

Country Status (5)

Country Link
US (1) US20090240627A1 (ko)
EP (1) EP2266085A4 (ko)
KR (1) KR20100135268A (ko)
CA (1) CA2719112A1 (ko)
WO (1) WO2009117618A2 (ko)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20150095952A (ko) * 2012-04-18 2015-08-21 구글 인코포레이티드 보안 요소를 갖지 않는 지불 거래들의 처리
KR20170008652A (ko) * 2015-07-14 2017-01-24 삼성전자주식회사 결제 시스템, 전자 장치 및 전자 장치의 결제 방법

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8463706B2 (en) * 2009-08-24 2013-06-11 Visa U.S.A. Inc. Coupon bearing sponsor account transaction authorization
US8336088B2 (en) * 2010-04-19 2012-12-18 Visa International Service Association Alias management and value transfer claim processing
US10360578B2 (en) 2012-01-30 2019-07-23 Visa International Service Association Systems and methods to process payments based on payment deals
US8825798B1 (en) 2012-02-02 2014-09-02 Wells Fargo Bank N.A. Business event tracking system
US9460436B2 (en) * 2012-03-16 2016-10-04 Visa International Service Association Systems and methods to apply the benefit of offers via a transaction handler
US9922338B2 (en) 2012-03-23 2018-03-20 Visa International Service Association Systems and methods to apply benefit of offers
US9864988B2 (en) 2012-06-15 2018-01-09 Visa International Service Association Payment processing for qualified transaction items
US9626678B2 (en) 2012-08-01 2017-04-18 Visa International Service Association Systems and methods to enhance security in transactions
US10438199B2 (en) 2012-08-10 2019-10-08 Visa International Service Association Systems and methods to apply values from stored value accounts to payment transactions
US10685367B2 (en) 2012-11-05 2020-06-16 Visa International Service Association Systems and methods to provide offer benefits based on issuer identity
US20230069258A1 (en) * 2021-08-26 2023-03-02 Centro De Pesquisas Avançadas Wernher Von Braun Digital network marketplace
US20230342736A1 (en) * 2022-04-26 2023-10-26 Visa International Service Association System, Method, and Computer Program Product for Managing Operation of a Remote Terminal

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4423287A (en) * 1981-06-26 1983-12-27 Visa U.S.A., Inc. End-to-end encryption system and method of operation
US4578530A (en) * 1981-06-26 1986-03-25 Visa U.S.A., Inc. End-to-end encryption system and method of operation
JP4270475B2 (ja) * 1997-08-13 2009-06-03 パナソニック株式会社 モバイル・エレクトロニックコマース・システム
US6000832A (en) * 1997-09-24 1999-12-14 Microsoft Corporation Electronic online commerce card with customer generated transaction proxy number for online transactions
US6128602A (en) * 1997-10-27 2000-10-03 Bank Of America Corporation Open-architecture system for real-time consolidation of information from multiple financial systems
MXPA01004945A (es) * 1998-11-17 2003-03-10 Prenet Corp Sistema de pago electronico utilizando cuenta intermediaria.
US7177848B2 (en) * 2000-04-11 2007-02-13 Mastercard International Incorporated Method and system for conducting secure payments over a computer network without a pseudo or proxy account number
JP5170918B2 (ja) * 2000-12-25 2013-03-27 株式会社三井住友銀行 決済代行システム、決済代行方法、決済代行プログラムを記録した記録媒体及び決済代行プログラム
KR20030048667A (ko) * 2001-12-12 2003-06-25 주식회사 엑스웨어솔루션 컴퓨터 네트워크를 통한 전자결제 중계 시스템 및 방법
US7346927B2 (en) * 2002-12-12 2008-03-18 Access Business Group International Llc System and method for storing and accessing secure data
US7761374B2 (en) * 2003-08-18 2010-07-20 Visa International Service Association Method and system for generating a dynamic verification value
US7287692B1 (en) * 2004-07-28 2007-10-30 Cisco Technology, Inc. System and method for securing transactions in a contact center environment
US7427033B1 (en) * 2005-02-26 2008-09-23 James Roskind Time-varying security code for enabling authorizations and other uses of financial accounts
US8762263B2 (en) * 2005-09-06 2014-06-24 Visa U.S.A. Inc. System and method for secured account numbers in proximity devices
AU2006342506A1 (en) * 2006-03-24 2007-11-01 Metabank Information management system and method

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20150095952A (ko) * 2012-04-18 2015-08-21 구글 인코포레이티드 보안 요소를 갖지 않는 지불 거래들의 처리
US9984360B2 (en) 2012-04-18 2018-05-29 Google Llc Processing payment transactions without a secure element
US10628817B2 (en) 2012-04-18 2020-04-21 Google Llc Processing payment transactions without a secure element
US11042861B2 (en) 2012-04-18 2021-06-22 Google Llc Processing payment transactions without a secure element
US11704645B2 (en) 2012-04-18 2023-07-18 Google Llc Processing payment transactions without a secure element
KR20170008652A (ko) * 2015-07-14 2017-01-24 삼성전자주식회사 결제 시스템, 전자 장치 및 전자 장치의 결제 방법

Also Published As

Publication number Publication date
EP2266085A2 (en) 2010-12-29
CA2719112A1 (en) 2009-09-24
US20090240627A1 (en) 2009-09-24
WO2009117618A3 (en) 2009-11-12
WO2009117618A2 (en) 2009-09-24
EP2266085A4 (en) 2012-08-08

Similar Documents

Publication Publication Date Title
US11887077B2 (en) Generating exchange item utilization solutions in an exchange item marketplace network
US11694207B2 (en) Securing an exchange item associated with fraud
KR20100135268A (ko) 지불 처리 시스템에서의 신뢰 에이전트 식별
US11694244B2 (en) Method for consumption based redemption in an exchange item marketplace network
US20230015356A1 (en) No point-of-sale terminal exchange item redemption
CN107851281B (zh) 用于基于区块链的交易的欺诈控制的系统和方法
CN111062720B (zh) 用于令牌域控制的系统和方法
US9292852B2 (en) System and method for applying stored value to a financial transaction
US8099368B2 (en) Intermediary service and method for processing financial transaction data with mobile device confirmation
US20160034896A1 (en) SYSTEMS AND METHODS FOR EXTENDING IDENTITY ATTRIBUTES AND AUTHENTICATION FACTORS IN AN ePAYMENT ADDRESS REGISTRY
US20160267472A1 (en) Securing digital gift cards with a public ledger
US20170372391A1 (en) Determining exchange item compliance in an exchange item marketplace network
CN109416791A (zh) 数字资产账户管理
US20120284187A1 (en) System and method for processing payment transactions
US20130013502A1 (en) Facilitation of Transactions Using a Transaction Code
US20210334794A1 (en) Resolving a parameter error associated with a primary blockchain
US20230125366A1 (en) Securely utilizing an exchange item unaffiliated with a merchant server
US20220414667A1 (en) Dynamically sharing an exchange item
US12033197B2 (en) Method and computer readable memory for securely facilitating extended use of an exchange item
US20230111668A1 (en) Point-of-sale fraud protection

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E601 Decision to refuse application