KR20070044496A - 자동화된 결제 승인 및 정산을 위한 방법 및 시스템 - Google Patents

자동화된 결제 승인 및 정산을 위한 방법 및 시스템 Download PDF

Info

Publication number
KR20070044496A
KR20070044496A KR1020077006240A KR20077006240A KR20070044496A KR 20070044496 A KR20070044496 A KR 20070044496A KR 1020077006240 A KR1020077006240 A KR 1020077006240A KR 20077006240 A KR20077006240 A KR 20077006240A KR 20070044496 A KR20070044496 A KR 20070044496A
Authority
KR
South Korea
Prior art keywords
payment
purchaser
transaction
invoice
settlement
Prior art date
Application number
KR1020077006240A
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 KR20070044496A publication Critical patent/KR20070044496A/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/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/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/14—Payment architectures specially adapted for billing 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/22—Payment schemes or models
    • G06Q20/24—Credit schemes, i.e. "pay after"
    • 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
    • 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
    • G06Q30/00—Commerce
    • G06Q30/04—Billing or invoicing
    • 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
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Finance (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Strategic Management (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Computer Security & Cryptography (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

본 발명은, 신용 카드 매입자(acquirer)(160) 및/또는 트랜잭션 프로세서(160)에 대한 구입자/결제자(110) 또는 공급자/수취인(130)을 대신하여, EIPP 서비스(120a)의 제3자 서비스 제공자(120a)로 하여금 인보이스 라인 항목 데이터(레벨 Ⅲ 데이터)로 결제 카드 트랜잭션의 승인 및 정산을 개시할 수 있도록 하는 시스템 및 방법을 제공한다. 결제 개시(550)는 사전 승인된 인보이스 혹은 구매 주문서에 대해 검증된 주문 확인서, 또는 구입자/결제자 조직(110)에 의해 승인되어 결제가 스케쥴링된(scheduled)(665) 인보이스 중 하나를 제출함으로써 이루어진다.
결제 카드, 전사적 자원 관리 시스템, 결제 네트워크 MS 게이트웨이, 인보이스, 구매 주문서, 주문 확인서

Description

자동화된 결제 승인 및 정산을 위한 방법 및 시스템{METHOD AND SYSTEM FOR AUTOMATED PAYMENT AUTHORIZATION AND SETTLEMENT}
본 발명은 자동화된 결제 승인 및 정산을 위한 방법 및 시스템에 관한 것이다.
본 출원은 "System and Method for Integrated Electronic Invoice Presentment and Payment"를 발명의 명칭으로 하는 2003년 6월 18일자로 출원된 미국 특허 출원 번호 10/465,394호를 우선권으로 하여 "Automated Payment Authorization and Settlement"라는 발명의 명칭으로 2004년 8월 25일자로 출원된 미국 가출원 번호 60/604,215호를 우선권으로 주장하며, 상기 2건의 특허 출원의 그 전체 내용이 본 명세서에 참고자료로 통합되어 있다. 본 출원은 또한 "Method and System for Automated Payment Authorization and Settlement"를 발명의 명칭으로 하여 2004년 10월 29일자 출원된 60/623,656호를 우선권으로 하며, 이 특허 또한 본 명세서에 참고자료로 통합되어 있다.
제3자 서비스 제공자(third-party service provider : "3SPS")를 이용하여 인보이스 발행 및 결제 처리를 자동화하기 위한 시도가 이루어져 왔다. 3PSP에는 Ariba™ 등의 전자 구매 제공자, Xign™ 등의 전자 인보이스 제시 및 결 제(electronic invoice presentment and payment : "EIPP") 제공자, 및 Oracle™ 등의 전사적 자원 관리("ERP") 제공자가 포함된다. 이러한 초기 3PSP 솔루션은 공급자/수취인/청구서발행자의 요구에 초점을 맞추었기 때문에, 구입자/결제자/결제업체(Buyer/Payer/payer)의 요구는 적절하게 해소하지 못하였다. 예컨대, 다수의 초기 3PSP 솔루션은, 결제의 개시를 효과적으로 그리고 효율적으로 통제하고, 결제의 정산을 지연하며, 이러한 결제의 정산을 구입자/결제자의 금융 시스템에 조정하여 통합하는 등의 구입자/결제자/결제업체의 결제 관련 요구사항을 해소하지 못하였다.
더욱이, 기존의 3PSP 솔루션은 통상적으로 신용 카드, 직불 카드, 법인 카드 또는 구매 카드 등의 결제 카드를 비지니스간 결제(business-to-business payment)의 수단으로서 이용하지 않는다. 또한, 이들 3PSP 솔루션은 결제 카드에 의한 결제 또는 결제 카드에 의한 결제에 앞서 구입자/결제자 인보이스 발행 규칙에 대한 검증에 연관된 결제 수단의 사용을 허용하지 않는다.
또한, 기존의 3PSP 솔루션은 결제 카드 데이터를 조직의 ERP 또는 어카운트 페이어블("A/P") 시스템과 같은 조직의 내부 시스템에 자동적으로 통합할 수 없다. 따라서, 조직은 인보이스 데이터를 수동으로 재입력하고, 그 인보이스 데이터를 조정을 목적으로 카드 트랜잭션과 매칭시키며, 그 후 그 데이터를 조직의 ERP 또는 A/P 시스템에 수동으로 입력하여야 한다. 이 과정은 시간이 많이 소요될 뿐만 아니라 사람에 의한 에러가 발생할 가능성이 크다.
일부의 기존의 3PSP 솔루션은 금융 전자 데이터 교환("EDI") 또는 다른 전자 결제 기술을 이용할 수도 있다. 그러나, 이들 결제 방법은 내부 시스템 및 프로세스에 대한 고비용의 변경을 포함한 상당한 셋업 비용을 요구할 것이며, 은행 관계(banking relationship)에 있어서의 변경을 필요로 할 것이다.
따라서, 기존의 프로세스 및 시스템에 통합하는데 비용 면에서 효율적이고 간편하며 또한 금융 기록의 효율적인 결제 및 조정을 가능하게 하는 자동화된 EIPP 방법 및 시스템에 대한 필요성이 존재한다.
미국 특허 출원 번호 10/465,394호에서, MasterCard는 가능한 결제 방법으로서 구매 카드를 이용하는 자동화된 전자 인보이스 제시 및 결제에 대한 시스템 및 방법을 제안하였다. 본 발명은 상기 특허 출원을 개량한 것이며, 본 발명에 의하면, 전자 구매 및/또는 인보이스 발행을 제공하는 3PSP가 자신의 고객으로 하여금 트랜잭션을 MasterCard 신용 카드 계정에서 자동적으로 정산하여, 그 고객들로 하여금 은행 신용 조건(bank credit terms)으로 구매 주문서("PO" : perchase order) 또는 인보이스 기반 구매를 행할 수 있도록 할 수 있다. 결제자는 지연된 결제 기간 및 발급 은행으로부터의 다수의 리베이트를 받을 기회의 이점을 갖는다. 공급자는 전자 결제 수령의 이점을 가지며(수표를 처리하는 비용에 비해), 하드웨어 또는 소프트웨어에 대한 추가의 투자 없이 레벨 Ⅲ 데이터를 통과시키는(더 낮은 할인율을 받을) 기회의 이점을 갖는다. 금융 기관 및 이들의 프로세서는 더 많은 양의 트랜잭션이 처리된다는 이점을 갖는다. 매입 기관 및 트랜잭션 프로세서의 예로는 Citibank, First Data Corporation, Global Payment, 및 Bank of America가 있다.
본 발명은, 신용 카드 매입자(acquirer) 및/또는 트랜잭션 프로세서에 대한 구입자/결제자/결제업체 또는 공급자/수취인(Payee)/수취업체를 대신하여, 3PSP로 하여금 인보이스 라인 항목 데이터(레벨 Ⅲ 데이터)로 결제 카드 트랜잭션의 승인 및 정산을 개시할 수 있도록 하는 시스템 및 방법을 제공한다. 결제 개시는 사전 승인된 인보이스 혹은 구매 주문서에 대해 검증된 주문 확인서, 또는 구입자/결제자/결제업체 조직에 의해 승인되어 결제가 스케쥴링된(scheduled) 인보이스 중 하나를 제출함으로써 이루어진다.
도 1은 결제자에 의해 결제가 개시되는 결제 카드 트랜잭션의 자동화된 결제 승인 및 정산을 위한 일례의 시스템을 예시하는 블록도이다.
도 2는 결제자에 의해 결제가 개시되는 결제 카드 트랜잭션의 자동화된 결제 승인 및 정산을 위한 일례의 방법을 예시하는 흐름도이다.
도 3은 수취인에 의해 결제가 개시되는 결제 카드 트랜잭션의 자동화된 결제 승인 및 정산을 위한 일례의 시스템을 예시하는 블록도이다.
도 4는 수취인에 의해 결제가 개시되는 결제 카드 트랜잭션의 자동화된 결제 승인 및 정산을 위한 일례의 방법을 예시하는 흐름도이다.
도 5는 본 발명의 일례의 실시예에 따른, 구매 주문서에 의해 개시되는 구매 카드 트랜잭션의 중간 정산을 예시하는 흐름도이다.
도 6은 본 발명의 일례의 실시예에 따른, 구매 주문서("PO")에 의해 개시되 는 구매 카드 트랜잭션의 지연된 정산을 예시하는 흐름도이다.
도 7은 본 발명의 일례의 실시예에 따른, 구매 주문서 없이 이루어지는(non-PO) 구매 카드 트랜잭션의 지연된 정산을 예시하는 흐름도이다.
도 8은 본 발명에 따른 MS 게이트웨이((merchant service gateway) 승인 및 정산의 일례의 프로세스를 예시하는 흐름도이다.
도 9는 본 발명에 따른 MS 승인 실패에 대한 조치를 행하는 일례의 프로세스를 예시하는 흐름도이다.
도 1 및 도 3은 결제 카드 트랜잭션의 자동화된 결제 승인 및 정산을 위한 일례의 시스템을 예시하는 블록도이다. 도 1에 도시된 일례의 실시예에서는 결제가 결제자에 의해 개시되는 반면, 도 3에 도시된 일례의 실시예에서는 결제가 수취인에 의해 개시된다. 도 1 및 도 3을 참조하면, 구입자/결제자(110) 및 공급자/수취인(130)은 각각 ERP 시스템(110a, 130a)을 포함하는 것이 바람직하다. 소프트웨어 제공자(120)는 예컨대 EIPP 시스템(120a) 등의 전자 구매, 인보이스 발행, 제시(presentment) 및/또는 결제 서비스를 제공하는 3PSP이다. 예컨대, 소프트웨어 제공자(120)로는 MasterCard e-P3™ EIPP 솔루션을 제공하는 Xign Corporation™이 가능하다.
매입자/프로세서(160)는 결제 카드 트랜잭션을 처리하는 금융 기관 또는 트랜잭션 프로세서이다. 결제 네트워크(170)는 MsterCard™ 결제 네트워크 등의 결제 카드 네트워크이다. 상인 서비스(merchant service : "MS") 결제 게이트웨 이(170a)는 이것을 통해 결제 카드 트랜잭션에 대한 승인 및 정산이 처리되는 것이 바람직한 게이트웨이이다. 발행 은행(140)은 구입자/결제자(110)에게 결제 카드를 발행하는 은행이다. MIS(150)는 발급 은행(140)의 관리 정보 시스템(management information system)이다. 도 3의 POS(Point-of-Sale) 기기(310)는 공급자/수취인(130)의 위치에서 또는 그 부근에서 금융 데이터를 받아들이고 그 데이터를 활성화, 승인 및 트랜잭션 기록(transaction logging)을 위해 결제 네트워크에 전송하는 판매 시점 관리 단말기, 또는 그와 유사한 종래의 시스템이다.
도 2는 구입자/결제자(110)에 의해 결제가 개시되는 결제 카드 트랜잭션의 자동화된 결제 승인 및 정산을 위한 일례의 방법을 예시하는 흐름도이다. 도 1 및 도 2를 참조하면, 단계 210에서, 구입자/결제자의 ERP(110a)는 인보이스에 대한 결제를 승인하여 스케쥴링한다. 본 실시예에서, 구입자/결제자의 ERP(110a)로는 예컨대 오라클 페이어블 시스템(Oracle payables system)이 가능하다. 단계 220에서, 소프트웨어 제공자(120)는 구입자/결제자의 ERP(110a)로부터 결제 파일을 추출하고, 그 결제 파일을 결제 승인 및 정산을 위해 매입자/프로세서(160)에게 보낸다. 예컨대, 결제 파일은 Oracle iPayment™ 또는 MasterCard e-P3™ 제공자에 의해 구입자/결제자의 오라클 페이어블 파이낸셜 시스템(Oracle Payables financial system)으로부터 추출될 수도 있다.
결제 파일은 ERP 인보이스 조정(ERP invoice reconciliation)을 위해 사용된 고유 트랜잭션 ID, 상인 ID(Merchant ID), 및 결제 카드 계정 정보를 포함하며, 인보이스 라인 항목 데이터(레벨 Ⅲ 데이터)를 포함할 것이다. 상인 ID는 공급자/수 취인(130)을 등록하는 처리 동안에 요구될 것이다. Oracle iPayment™ 등의 소프트웨어 제공자(120)는 예컨대 Oracle Payables 등의 구입자/결제자의 ERP(110a) 또는 소프트웨어 제공자(120)의 결제 인터페이스(120a) 중의 하나로부터 결제 카드 계정 정보를 획득할 수도 있다.
단계 230에서, 구입자/결제자(110)의 결제 카드 결제 요청은 승인 및 정산을 위해 예컨대 MasterCard의 결제 네트워크 등의 결제 네트워크(170)에 제출된다. 단계 240에서, 결제 카드 계산서 데이터가 발급 은행의 MIS 어플리케이션(150)을 통해 또는 결제 네트워크(170)로부터 직접 구입자/결제자(110)에 제공된다. 결제 카드 계산서 데이터는 결제 파일로부터의 고유 트랜잭션 ID를 포함하는 것이 바람직하다(단계 220 참조).
단계 250에서, 소프트웨어 제공자(120)는 고유 트랜잭션 ID를 포함한 결제 송금 데이터를 매입자/프로세서(160)에 의해 제공된 은행 계산서를 이용한 조정을 위해 공급자/수취인(130)에게 제공한다. 예컨대, 결제 송금 데이터는 은행 계산서를 이용한 조정을 위해 Oracle iPayment™ 등의 e-P3™ 제공자에 의해 공급자/수취인(130)에게 제공될 수도 있다. 최종적으로, 단계 260에서, 구입자/결제자(110)는 결제 카드 트랜잭션을 요금청구 사이클(billing cycle)의 종료 시에 발급 은행(140)과 정산한다.
도 4는 공급자/수취인(130)에 의해 결제가 개시되는 결제 카드 트랜잭션의 자동화된 결제 승인 및 정산을 위한 일례의 방법을 예시하는 흐름도이다. 도 3 및 도 4를 참조하면, 단계 410에서, 구입자/수취인의 ERP(110a)는 인보이스에 대한 결 제를 승인하여 스케쥴링한다. 단계 420에서, 소프트웨어 제공자(120)는 구입자/결제자의 ERP 시스템(110a)으로부터 결제 파일을 추출하고, 그 결제 파일을 결제 승인 및 정산을 위해 공급자/수취인(130)에게 전송한다(예컨대, 이메일에 의해). 결제 파일은 ERP 인보이스 조정을 위해 사용된 고유 트랜잭션 ID, 상인 ID, 결제 카드 계정 정보를 포함하며, 인보이스 라인 항목 데이터(레벨 Ⅲ 데이터)를 포함할 수도 있다. 상인 ID는 공급자/수취인(130)을 등록시키는 처리 동안 요구된다. 소프트웨어 제공자(120)는 구입자/결제자의 ERP(110a) 또는 소프트웨어 제공자의 결제 인터페이스(120a) 중의 하나로부터 결제 카드 계정 정보를 획득한다.
단계 430에서, 공급자/수취인(130)은 결제 카드 및 기타 트랜잭션 정보를 승인 및 정산을 목적으로 POS 기기(310)를 통해 매입자/프로세서(160)에 제출한다. 매입자/프로세서는 승인 및 정산 정보를 결제 네트워크(170)를 통해 송부(route)한다. 단계 440에서, 소프트웨어 제공자(120)는 고유 트랜잭션 ID를 포함하는 인보이스 라인 항목 데이터를 매칭을 목적으로 결제 네트워크(170)에 직접 보낸다.
단계 450에서는, 결제 카드 계산서 데이터가 발행 은행의 MIS 어플리케이션(150)을 통해 또는 결제 네트워크(170)로부터 직접 구입자/결제자(110)에 제공된다. 결제 카드 계산서 데이터는 결제 파일로부터의 고유 트랜잭션 ID를 포함하는 것이 바람직하다(단계 420 참조). 단계 460에서, 결제 송금 데이터가 조정을 목적으로 매입자/프로세서(160)에 의해 공급자/수취인(130)에 제공된다. 최종적으로, 단계 470에서, 구입자/결제자(110)는 청구 사이클의 종료 시에 결제 카드 트랜잭션을 발행 은행(140)과 정산한다.
이하에서는 본 발명의 또 다른 예의 실시예를 설명한다. 이러한 예의 실시예에서는 MasterCard의 P-Card™ 등의 구매 카드를 사용하는 것으로 나타내고 있지만, 다른 임의의 어떠한 결제 카드도 사용될 수 있다. 본 발명은 EIPP 플랫폼(120a)을 제공하는 소프트웨어 제공자(120)와, 또한 공급자/수취인(130) 등록, 결제 승인 및/또는 정산 요청과 응답, 및 예외 워크플로우 통보(exception workflow notification)를 자동화하고 통합하는 기능을 구성하는 매입자/프로세서(160) 양자를 지원한다.
본 명세서에 개시된 일례의 실시예에서는 상인 서비스("MS") 결제 게이트웨이(170a)(도 1 및 도 3)가 채용되는 것이 바람직하다. MS 게이트웨이(170a)는 이것을 통해 구매 카드 트랜잭션을 위한 승인 및 정산이 처리되는 것이 바람직한 게이트웨이이다. 이러한 처리는 레벨 Ⅲ 트랜잭션을 축적하여 주기적인 기간에 예컨대 810 EDI 포맷 등의 표준 데이터 교환 포맷으로 MS 게이트웨이(170a)에 보내는 일괄 모드(batch mode)로 수행될 수도 있다. MS 게이트웨이(170a)는 트랜잭션을 적합한 지점으로 송부하기 위해 상인 식별자("Merchant ID")에 기초하여 트랜잭션을 나누는 것이 바람직하다. MS 게이트웨이(170a)는 승인 응답을 예컨대 824 EDI 포맷 등의 표준 데이터 교환 포맷으로 되돌려 주는 것이 바람직하다. 승인된 트랜잭션에 대해, MS 결제 게이트웨이(170a)는 제공되었던 레벨 Ⅲ 데이터와의 정산 처리로 진행하는 것이 바람직하다.
도 5는 본 발명의 일례의 실시예에 따른 구매 주문서("PO")에 의해 개시된 구매 카드 트랜잭션의 중간 정산을 나타내는 흐름도이다. 단계 505에서, 구입자/ 결제자(110)는 구매 주문서(PO)를 구입자/결제자(110)의 ERP 시스템(110a)에서 소프트웨어 제공자의 EIPP 시스템(120a)으로 전자 문서 형태로 발송한다. 단계 510에서, PO 파일이 요구된 포맷으로 EIPP 시스템(120a)에 발송된 후, PO 로드 프로세스(PO Load process)가 호출되어 PO를 변환 및 구문분석(parse)하여 EIPP 시스템(120a)에 로드한다.
단계 515에서, PO가 EIPP 시스템(120a)에 로드되고 포맷 및 구조에 대해 검증된 후, EIPP 시스템(120a)은 PO에 대해 포스트-로드 분석(post-load analysis)을 개시한다. 포스트-로드 분석은, (ⅰ) 공급자/수취인(130) 및 구입자/결제자(110)에 대한 정보가 PO 헤더(header)에서 이용 가능한지를 판정하고, (ⅱ) 결제 방법으로서 제공되는 구매 카드 정보를 결정하여 검증하고, (ⅲ) 그 구매 카드 정보가 신규의 PO, 복사 PO 또는 변경된 PO인지를 판정하고, 그 후의 처리를 위해 이러한 상황을 적절하게 플래그(flag)하고, (ⅳ) 결제 기간, 즉 중간 PO인지 아니면 지연된 PO인지를 판정하는 등의 일련의 기본적인 검증을 포함한다.
단계 520에서, 포스트 로드 PO 분석이 완료된 후, PO가 그 후의 처리를 위해 신규 PO로서 플래그되어야 하는지 아니면 변경된 PO로서 플래그되어야 하는지의 여부가 결정되는 것이 바람직하다. 예외(exception)의 경우, PO는 적합한 이유와 함께 에러로서 플래그되고, 단계 523에서 예외 대기열(exception queue)에 보내진다. 단계 525에서, PO가 변경된 PO로서 플래그되었다면, EIPP 시스템(120a)은 "변경된 PO" 처리를 개시한다. 원래의 PO가 이행되었는지의 여부에 따라 그리고 구입자/결제자(110)와 공급자/수취인(130) 간의 관계에 대해 정의된 규칙에 기초하여, 시스 템은 그 변화를 PO에 적용하도록 진행하고, PO 히스토리를 생성한다.
변경된 PO의 경우, 단계 525에서 적합한 처리가 완료된 후, 단계 530에서는 그 변화가 유효한 것인지의 여부가 판정되는 것이 바람직하다. 그 변화가 유효하지 않다면, PO는 에러로서 플래그되고, 단계 523에서 예외 대기열에 보내진다. 그 변화가 유효한 것이라면, PO는 공급자/수취인(130) 셋업 정보 및/또는 PO로부터 획득되는 벤더 ID/고객 계정 번호의 세부사항을 이용하여 공급자/수취인(130)의 하나 이상의 에이전트에게 송부된다. 공급자/수취인(130)에게는 PO에 대해 알려주기 위해 이메일 통보가 발송되는 것이 바람직하다.
단계 535에서, 공급자/수취인(130)의 에이전트는 자신에게 송부되는 모든 PO의 개요를 확인할 수 있는 것이 바람직하다. PO가 그와 관련된 구매 계정 번호를 갖는다면, 그 PO에 대한 개요 라인은 이러한 상황을 나타내는 것이 바람직하다. 또한, PO에 대한 개요 라인은 결제 기간이 임박하였는지의 여부를 나타내줄 것이다. 공급자/수취인(130)의 에이전트는 확인하고자하는 PO의 세부사항을 선택할 수 있다. 그에 따라, PO 세부사항 화면이 제공될 것이다. PO 세부사항 화면에는 매스킹된 구매 카드 정보(masked purchasing card information) 또한 이용 가능할 것이다.
단계 540에서, PO 개요 또는 PO 세부사항 화면으로부터, 구입자/수취인(130)의 에이전트는 구매주문서(PO)를 플립(flip : 한장씩 넘김)할 수도 있다. 에이전트는 PO 세부사항의 편집 가능한 인터페이스(구입자/결제자(110)에 의해 정해진 바와 같은)가 제공된다. 이 단계에서도, 구매 카드 번호는 매스킹된 채로 유지된다. 공급자/결제자(130)의 에이전트는 수량과 함께 주문 확인서에 포함될 요소를 선택한다. 공급자/수취인(130)의 에이전트가 플립(부분적으로 또는 전체적으로)을 행하도록 진행할 때, 시스템은 드래프트 주문 확인서를 생성한다. 드래프트 주문 확인서는 PO에 이용 가능한 경우에 그 값이 사전에 채워지는 세금(Tax) 및 FOB에 대한 편집 가능한 필드를 갖는다. 공급자/수취인(130)의 에이전트는 이들 요소들을 무시할 수도 있으며, 또한 생성된 인보이스 번호를 무시하고 주문 확인서를 생성하도록 진행할 수도 있다.
단계 545에서는, PO의 상태가 "결제를 처리중(processing payment)" 상태로 변화하며, EIPP 시스템(120a)은 고유 번호를 생성하여 주문 확인서와 연관시킨다. 단계 550에서는, 공급자/수취인(130)이 MS 게이트웨이에 의해 매입(acquire)되었는지의 여부에 기초하여, 적합한 결제 관련 프로세스가 개시된다. 단계 555에서, 공급자/수취인(130)이 MS 게이트웨이(170a)에 의해 매입되지 않았다면, 공급자/수취인(130)에 제공되는 주문 확인서 화면은 수동 결제 승인 처리를 개시하기 위한 옵션을 가질 것이다.
단계 560에서, 수동 옵션의 선택 시, 공급자/수취인(130)은 승인 코드 및 트랜잭션 일자를 입력하기 위한 편집 가능한 필드를 갖는 주문 확인서의 화면이 제공된다(시스템 일자는 이미 위치되어 있음). 고유 번호 또한 이 스크린 상에 제공될 수도 있다. 이 단계에서, 구매 카드 번호는 매스킹이 제거될 수도 있다. 공급자/수취인(130)은 외부 POS 기기(310)를 통해 승인하며, 예컨대 고객 코드에 대해 촉구될 시에 POS 기기(310)에 고유 번호를 입력한다.
단계 565에서, 승인된 경우, 공급자/수취인(130)은 승인 코드 및 트랜잭션 일자를 가지고 주문 확인서를 갱신하며, 주문 확인서를 "결제됨(paid)"으로서 플래그하도록 진행한다. 결제 승인이 거부되거나 실패한 경우, 구입자/결제자(110) 및 공급자/수취인(130) 양자는 이메일을 통해 이러한 상황에 대해 통보되며, 그 인보이스는 "실패됨(failed)"으로서 플래그되고, "실패한 승인" 개요 화면 또는 바스킷("Failed Authorization" summary view or basket)에 위치된다.
단계 550에서, 공급자/수취인(130)이 MS 게이트웨이(170a)에 의해 매입되었다면, EIPP 시스템(120a)은 단계 570에서 MS 게이트웨이 승인 및 정산 프로세스로 진행한다. MS 게이트웨이 승인 및 정산 프로세스(단계 570)는 승인/정산 파일이 EIPP 시스템(120a)에 의해 생성되어 MS 게이트웨이(170a)에 보내지는 일괄 프로세스(batch process)인 것이 바람직하다. 승인/정산 파일은 레벨 Ⅲ 정산 데이터를 포함한다. 단계 575에서, EIPP 시스템(120a)은 MS 게이트웨이(170a)로부터 승인 코드를 포함하고 있는 응답을 수신하며, 주문 확인서를 승인된 것으로서 즉 "결제됨"으로서 플래그하고, 그 승인 코드를 주문 확인서와 연계시킨다. 결제 승인이 거부되거나 실패한 경우, 구입자/결제자(110) 및 공급자/수취인(130) 양자는 이메일을 통해 통보되며, 그 인보이스는 "실패한 승인"으로서 플래그되고, "실패한 승인" 개요 화면 또는 바스킷에 위치된다. MS-기반 승인에 대해, 트랜잭션은 적합한 이유 코드를 포함하는 것이 바람직하다.
공급자/수취인(130)은 개요 수준으로 생성되는 상이한 주문 확인서를 확인할 수 있고 또한 특정 주문 확인서를 선택하여 상세하게 확인할 수 있는 옵션을 가질 수도 있다. 공급자/수취인(130)(non-MS)이 플립에 후속하여 어떠한 동작을 취하지 않도록 선택할 수도 있는 특정 주문 확인서가 있을 수도 있다. 이들은 "수동 승인을 대기중(Awaiting Manual Authorization)"으로서 플래그될 것이다.
단계 580에서, 주문 확인서가 "결제됨"으로서 플래그된 후, 관련 정보가 특정 XML 스키마(schema)로 표시되어, 외부로 보내질 수도 있는 EIPP 시스템(120a)의 XML 파일에 첨부될 것이다. 한편, 주문 확인서는 또한 EIPP 시스템(120a)에 정의된 송부 규칙(routing rule)에 기초하여 구입자/결제자(110)에게 송부된다. 인보이스/주문 확인서 개요 라인 항목과 함께, 그 문서가 주문 확인서라는 것을 나타내는 표식(indicator)이 존재하는 것이 바람직하다. 구입자/결제자(110)는 구매 카드 세부사항(계정 번호의 끝에서 4자리를 제외한 나머지 구매 카드 세부사항은 매스킹됨)과 함께 주문 확인서 세부사항을 확인할 수도 있다. 구입자/결제자(110)는 주문 확인서를 어카운트 페이어블 시스템(account payable system)과 통합하기 위해 외부로 보내는 것을 제외하고는 주문 확인서에 대해 추가의 처리를 행하지 않는 것이 바람직하다.
도 6은 본 발명의 일례의 실시예에 따른 PO에 의해 개시된 구매 카드 트랜잭션의 지연된 정산을 도시하는 흐름도이다. 단계 605에서, 구입자/결제자(110)는 PO를 구입자/결제자의 ERP(110a)로부터 소프트웨어 제공자의 EIPP 시스템(120a)으로 전자 문서 형태로 발송한다. 단계 610에서, PO 파일이 요구된 포맷으로 EIPP 시스템(120a)에 발송된 후, PO 로드 프로세스가 호출되어, PO를 변환 및 구문분석하여 EIPP 시스템(120a)에 로드한다.
단계 615에서, PO가 EIPP 시스템(120a)에 로드되어 포맷 및 구조에 대해 검증된 후, EIPP 시스템(120a)은 PO에 대해 포스트-로드 분석(post-load analysis)을 개시한다. 포스트-로드 분석은, (ⅰ) 공급자/수취인(130) 및 구입자/결제자(110)에 대한 정보가 PO 헤더에 이용 가능한지의 여부를 판정하고, (ⅱ) 결제 방법으로서 제공되는 구매 카드 정보를 판정 및 검증하며, (ⅲ) 신규의 PO인지, 복사 PO인지 아니면 변경된 PO인지를 판정하고, 판정된 내용을 그 후의 처리를 위해 적절하게 플래그하고, (ⅳ) 결제 기간 즉 중간 PO인지 아니면 지연된 PO인지를 결정하는 등의 일련의 기본적인 검증을 포함한다. 본 예의 실시예에서, 지연된 PO는 예컨대 "net 15", "net 30" 등의 결제 기간을 가질 수도 있다. 결제 기간이 전혀 없을 수도 있으며, 이것은 지연된 PO의 특별한 경우에 고려될 것이다.
단계 620에서, 포스트-로드 PO 분석이 완료된 후, PO가 그 후의 처리를 위해 신규 PO로서 플래그되어야 하는지 아니면 변경 PO로서 플래그되어야 하는지의 여부가 판정되는 것이 바람직하다. 예외(exception)의 경우, PO는 적합한 이유와 함께 에러로서 플래그되고, 예외 대기열(623)에 보내진다. 단계 625에서, PO가 변경된 PO로서 플래그되었다면, EIPP 시스템(120a)은 변경된 PO 처리를 개시한다. 원래의 PO가 이행되는지의 여부에 따라 그리고 구입자/결제자(110) 및 공급자/수취인(130) 간의 관계에 대해 정해진 규칙에 기초하여, EIPP 시스템(120a)은 PO에 변경을 적용하고, PO 히스토리를 생성한다. 변경된 PO의 경우, 적합한 처리가 단계 625에서 완료된 후, 단계 630에서는 그 변경이 유효한 것인지의 여부가 판정되는 것이 바람직하다. 그 변경이 유효하지 않은 것이라면, PO는 에러로서 플래그되고, 예외 대 기열(623)에 보내진다. 그 변경이 유효하다면, PO는 PO로부터 획득되는 것이 바람직한 벤더 ID/고객 계정 정보 세부사항 또는 공급자/수취인(130) 셋업 정보를 이용하여 공급자/수취인(130)의 하나 이상의 에이전트에 해당하는 것으로 표시되거나 송부된다. 공급자/수취인(130)에게 PO에 대해 알려주기 위해 이메일 통보가 발송되는 것이 바람직하다.
단계 635에서, 공급자/수취인(130)의 에이전트는 자신에게 송부되는 모든 PO의 개요를 확인할 수 있는 것이 바람직하다. PO가 그와 관련된 구매 계정 번호를 갖는다면, 그 PO에 대한 개요 라인은 이러한 상황을 나타내주는 것이 바람직하다. 또한, PO에 대한 개요 라인은 결제 기간이 임박하였는지의 여부를 나타낼 것이다. 공급자/수취인(130)의 에이전트는 확인하고자 하는 PO의 세부사항을 선택할 수 있다. 그에 따라, PO 세부사항 화면이 제공될 것이다. PO 세부사항 화면에는 매스킹된 구매 카드 정보 또한 이용 가능할 것이다.
단계 640에서, PO 개요 또는 PO 세부사항 화면으로부터, 구입자/수취인(130)의 에이전트는 플립하고자 하는 PO를 선택할 수 있다. 에이전트는 PO 세부사항의 편집 가능한 인터페이스(구입자/결제자(110)에 의해 정해진 바와 같은)가 제공된다. 이 단계에서도, 구매 카드 번호는 매스킹된 채로 유지된다. 공급자/결제자(130)의 에이전트는 수량과 함께 인보이스에 포함될 요소를 선택한다. 공급자/수취인(130)의 에이전트가 플립(부분적으로 또는 전체적으로)을 행하도록 진행할 때, EIPP 시스템은 단계 645에서 드래프트 인보이스를 생성한다. 드래프트 인보이스는 PO에 이용 가능한 경우에 그 값이 사전에 채워지는 세금(Tax) 및 FOB에 대한 편집 가능한 필드를 갖는다. 공급자/수취인(130)의 에이전트는 이들 요소들을 무시할 수 있으며, 또한 생성된 인보이스 번호를 무시하고, 단계 645에서 주문 확인서를 생성하도록 진행할 수도 있다.
단계 645에서, 생성된 인보이스는 승인 및 스케쥴링(scheduling)을 위해 적합한 구입자/결제자(110)의 에이전트에게 송부된다. 이러한 송부는, 구입자/결제자(110) 송부 구축(routing setup)에 의해 그리고 원래의 PO로부터 획득된 고객 계정 번호 및 구입자/결제자(110)에 대한 어떠한 다른 관련 정보에 의해 결정된다.
단계 650에서, 구입자/결제자(110)의 에이전트는 구입자/결제자(110)의 ID에게 송부되는 모든 인보이스의 개요를 확인할 수도 있다. PO 개요는, 예컨대 특수한 로고를 이용하여, 자신과 연관된 구매 카드 트랜잭션을 갖는 임의의 PO를 나타내는 것이 바람직하다. 구입자/결제자(110)의 에이전트는 확인하고자 하는 인보이스의 세부사항을 선택할 수도 있다. 구매 카드 정보 또한 이러한 상세 화면에 제공된다. 구매 카드 번호는 뒤쪽의 4 자리를 제외하고는 매스킹된 채로 유지된다.
단계 655에서, 구입자/결제자(110)의 에이전트는 승인을 위해 인보이스를 송부할 수도 있다. 구입자/결제자(110)의 에이전트는 인보이스를 승인하거나 및/또는 그 인보이스를 구입자/결제자(110)의 조직에 대해 정해진 워크플로우를 이용하여 다른 에이전트에 포워딩할 수도 있다. 단계 660에서, PO가 인보이스에 임의의 결제 기간을 첨부하였는지와, 결제 기간을 첨부한 경우 그 결제 기간이 어떻게 되는지에 대한 판정이 이루어진다. 구매주문서(PO)에 지연된 결제 기간이 명시되어 있다면, 단계 665에서는, 생성된 인보이스가 이러한 기간에 기초하여 스케쥴링 및 승인된다. 예컨대, 결제 기간이 "Net 15"로 나타내어져 있다면, 인보이스는 구입자/결제자(110)가 확인 가능하게 된 일자로부터 15일 후에 결제가 스케쥴링되는 것이 바람직하다. 그러나, 결제 기간이 공란이면, 단계 667에서 구입자/결제자는 그 인보이스를 추후의 일자에 승인 및 결제하도록 스케쥴링할 것이다. 단계 655에서, 인보이스가 승인된 후, 승인된 인보이스는 단계 665에서의 확인을 위해 공급자/수취인에게 송부된다.
단계 670에서, 스케쥴링된 일자에 도달하는 즉시, 인보이스의 상태가 "결제를 처리중" 상태로 변경된다. 고유 번호가 생성되어 인보이스와 연관되는 것이 바람직하다. 단계 670에서, 공급자/수취인이 MS 게이트웨이(170a)에 의해 매입되었는지에 기초하여, 적절한 결제 관련 프로세스가 개시된다. 공급자/수취인(130)이 MS 게이트웨이(170a)에 의해 매입되었다면, EIPP 시스템(120a)은 단계 675로 진행하여 MS 게이트웨이(170a) 승인 및 정산 프로세스를 진행한다.
MS 게이트웨이(170a) 승인 및 정산 프로세스는 승인/정산 파일이 EIPP 시스템(120a)에 의해 생성되어 MS 게이트웨이(170a)에 보내지는 일괄 프로세스인 것이 바람직하다. 승인/정산 파일은 레벨 Ⅲ 정산 데이터를 포함하는 것이 바람직하다. EIPP 시스템(120a)은 승인 코드를 포함하는 MS 게이트웨이(170a)로부터 응답을 수신하고, 단계 680으로 진행하여 그 인보이스를 승인된 것으로서 플래그하고, 즉 그 인보이스를 "결제됨"으로서 플래그하고, 그 승인 코드를 인보이스와 연계시킨다.
결제 승인이 거부되거나 실패하면, 구입자/결제자(110) 및 공급자/수취인(130) 양자가 이-메일을 통해 통보되며, 그 인보이스가 단계 680에서 적합하게 플래그되어, "실패한 승인" 개요 화면 또는 바스킷에 위치된다. MS 게이트웨이(170a) 승인에 대해, 트랜잭션은 적절한 이유 코드를 포함하는 것이 바람직하다.
단계 670에서, 인보이스가 스케쥴링된 일자에 도달하여 "결제를 처리중" 상태에 있을 때, 상인이 매입되지 않았는지, 즉 공급자/수취인(130)이 "수동 승인을 대기중"으로서 플래그되어 있는지의 여부가 판정되며, 단계 685에서는 수동 승인 프로세스가 트리거된다. 공급자/수취인(130)이 수동 승인을 대기하고 있는 인보이스의 세부사항을 확인할 때, 결제 처리를 개시하기 위한 옵션이 공급자/수취인(130)에게 제공된다. 이 옵션의 선택 시, 공급자/수취인(130)은 승인 코드 및 트랜잭션 일자를 입력하기 위한 편집 가능한 필드를 갖는 인보이스의 화면이 제공된다(시스템 일자는 사전에 위치됨). 고유 번호 또한 이 스크린 상에 나타내진다. 이 단계에서, 구매 카드 번호는 매스킹이 제거된다. 공급자/수취인(130)은 외부 POS 기기를 통해 승인하고, 예컨대 고객 코드에 대해 촉구될 시에 POS 기기에 고유 번호를 입력한다. 승인된 후, 공급자/수취인(130)은 승인 코드 및 트랜잭션 일자로 인보이스를 갱신하고, 그 인보이스를 "결제됨"으로서 플래그하도록 진행한다.
결제 승인이 거부되거나 실패하면, 구입자/결제자(110) 및 공급자/수취인(130) 양자는 이메일을 통해 통보되며, 단계 690에서 그 인보이스가 플래그되며, "실패한 승인" 개요 화면 또는 바스킷에 위치된다. 결제 승인이 성공적이면, 단계 690에서는, 인보이스가 "결제된" 것으로서 플래그되고, 단계 695에서 관련 정보가 외부로 보내지기 위해 EIPP XML 파일에 첨부된다.
도 7은 본 발명의 일례의 실시예에 따른 구매 주문서(PO) 없이 이루어지는 구매 카드 트랜잭션의 지연된 정산을 예시하는 흐름도이다. 본 예의 실시예에서, EIPP 시스템(120a)에 로드되는 PO가 존재하지 않는다. 단계 710에서는, 인보이스가 공급자/수취인(130)에 의해 소프트웨어 공급자(120)에게 전자 문서 형태로 발송된다. 소프트웨어 제공자(120) 측에서는, 단계 715에서 인보이스가 EIPP 시스템(120a)에 로드된다. 인보이스 로드 프로세스 동안, EIPP 시스템(120a)은 공급자/수취인(130)이 결제 방법으로서 구매 카드를 수락하는지를 식별하는 것이 바람직하다. 또한, 특정 고객 계정(구입자/결제자-공급자/수취인 관계 수준에서 정해진)에 대한 디폴트 결제 방법으로서 구매 카드가 정해졌다면, EIPP 시스템(120a)은 그 계정을 인보이스에 연계시킬 것이다.
구입자/결제자(110)는 구매 카드를 이용하여 결제를 이루기 위해 승인될 복수의 에이전트를 포함하는 사용자 그룹을 설정할 수도 있다. 구입자/결제자(110)의 관리자는 카드 소지자 성명, 카드 번호, 만료 일자, 및 CVC2 코드 등의 구매 카드 세부사항을 입력하고, 그 구매 카드를 하나 이상의 사용자 그룹과 연계시킬 것이다. 구입자/결제자(110)의 관리자는 구매 카드가 특정의 구체적인 공급자/수취인(130)에 대해서만 이용되는 것으로 간주할 수도 있다.
단계 715에서, 인보이스는 그 인보이스로부터 이용 가능한 송부 정보(routing information)에 기초하여 적절한 구입자/결제자(110)에 로드 및 송부된다. 송부는 송부 ID 또는 고객 계정 번호에 기초하여 행해질 수도 있다. 단계 720에서, 구입자/결제자(110)의 에이전트는 그 ID에 송부되는 모든 인보이스의 개요를 확인할 수도 있다. 단계 725에서, 구입자/결제자(110)의 에이전트는 인보이 스를 승인하거나 및/또는 그 인보이스를 구입자/결제자(110)의 기관에 대해 정해진 워크플로우를 이용하여 다른 에이전트에게 포워딩할 수도 있다. 구입자/결제자(110)의 에이전트는 결제 방법으로서 "구매 카드"를 선택할 수도 있거나, 또는 "구매 카드"가 이미 특정 고객 계정에 대한 디폴트 결제 방법으로서 정해져 있을 수도 있으며, 그 경우 EIPP 시스템(120a)은 구매 카드를 인보이스에 이미 연계하고 있을 것이다.
단계 730에서, "구매 카드"가 결제 옵션으로서 확정된 후, 인보이스는 추후의 일자에 결제를 위해 자동으로 스케쥴링되거나, 또는 "스케쥴러" 특권("scheduler" privilege)을 갖는 구입자/결제자(110)의 에이전트에 의해 수동으로 스케쥴링된다. 단계 735에서, 구매 카드 세부사항은 인보이스와 자동으로 연계된다. 단계 740에서, 이 인보이스는 결제를 위해 승인되어, 단계 745에서 확인을 위해 공급자/수취인(130)에게 송부된다.
단계 750에서, 스케쥴링된 일자에 도달할 때에, 인보이스의 상태는 "결제를 처리중" 상태로 변경되고, 고유 트랜잭션 번호가 생성되어 인보이스와 연계된다. 단계 755에서는, 공급자/수취인(130)이 MS 게이트웨이(170a)에 의해 매입되었는지의 여부에 기초하여, 적합한 결제 관련 프로세스가 개시된다. 단계 760 및 765에서, 공급자/수취인(130)이 MS 게이트웨이(170a)에 의해 매입되었다면, EIPP 시스템(120a)은 MS 게이트웨이 승인 및 정산 프로세스로 진행한다. MS 게이트웨이 승인 및 정산은 EIPP 시스템(120a)에 의해 승인/정산 파일이 생성되어 MS 게이트웨이(170a)에 발송되는 일괄 프로세스인 것이 바람직하다. 승인/정산 파일은 레벨 Ⅲ 정산 데이터를 포함하는 것이 바람직하다.
단계 770에서, EIPP 시스템(120a)은 승인 코드를 포함하고 있는 응답을 MS 게이트웨이(170a)로부터 수신하며, 그 인보이스를 승인된(결제된) 것으로서 플래그하고 승인 코드를 그 인보이스와 연계시킨다. 결제 승인이 거부되거나 실패하면, 구입자/결제자(110) 및 공급자/수취인(130) 양자는 이메일을 통해 통보되며, 그 인보이스가 "실패한 승인"으로서 플래그되어, "실패한 승인" 개요 화면/바스킷에 위치된다. MS 게이트웨이(170a) 승인에 대해, 트랜잭션은 적합한 이유 코드를 포함할 것이다.
단계 755에서, 상인이 매입되지 않은 것으로, 즉 공급자/수취인(130)이 "수동 승인을 대기중"으로서 플래그된 것으로 판정되면, 단계 775에서는 수동 승인 프로세스가 트리거된다. 공급자/수취인(130)이 이러한 인보이스의 세부사항("수동 승인을 대기중")을 확인할 때, 결제 처리를 개시하기 위한 옵션이 공급자/수취인(130)에게 제공된다. 이 옵션의 선택 시, 공급자/수취인(130)은 승인 코드 및 트랜잭션 일자를 입력하기 위한 편집 가능한 필드를 갖는 인보이스의 화면이 제공될 수도 있다(시스템 일자는 이미 위치됨). 이 스크린 상에는 고유 번호 또한 제공된다. 이 때, 구매 카드 번호는 매스킹이 제거되는 것이 바람직하다. 공급자/수취인(130)은 외부 POS 기기(310)를 통해 승인하고, 예컨대 고객 코드에 대해 촉구될 때에는 POS 기기(310)에 고유 번호를 입력한다.
단계 780에서, 승인된 후, 공급자/수취인(130)은 인보이스를 승인 코드 및 트랜잭션 일자로 갱신하고, 그 인보이스를 "결제됨"으로서 플래그하도록 진행한다. 단계 780에서, 결제 승인이 거부되거나 실패하면, 구입자/결제자(110) 및 공급자/수취인(130) 양자는 이메일을 통해 통보되며, 그 인보이스가 "실패한 승인"으로서 플래그 되어, "실패한 승인" 개요 화면/바스킷에 위치된다. 단계 785에서, 인보이스가 "결제됨"으로서 플래그된 후, 관련 정보가 표시되고, 외부로 보내기 위해 EIPP 시스템(120a)의 XML에 첨부된다.
이하에서는, 본 발명에 따른 MS 게이트웨이 승인 및 정산에 대한 일례의 프로세스에 대한 흐름도를 도시하는 도 8을 참조하여 MS 승인 및 정산을 보다 상세하게 설명할 것이다. MS 승인 및 정산은 서로 결합된 일괄 프로세스인 것이 바람직하지만, 반드시 그러할 필요는 없으며, 승인과 정산 양자가 별개의 프로세스가 될수도 있다. MS 승인 및 정산은 또한 백엔드 프로세스(backend process), 즉 사용자가 프로세스 실행을 보지 못하는 것이 바람직하다.
단계 820에서는, 단계 810에서의 트리거에 기초하여 승인/정산 트랜잭션 레코드가 작성된다. 트리거는 주문 확인 인보이스가 생성될 때와 그 인보이스가 "결제를 처리중" 상태에 도달할 때인 것이 바람직하다. 이 트리거가 작동될 때, 기본 요소(base element)만을 포함하는 기본 파일(base file)이 스케쥴링을 기반으로 작성되는 것이 바람직하다. 신규 파일 또한 MS에 대한 전송이 있을 때에 작성된다. 이 파일에는, 결제 트랜잭션이 EIPP 시스템(120a) 내에서 발생할 때에, 레코드가 추가되는 것이 바람직하다. 소정의 시각에, 이 파일은 MS 게이트웨이(170a)에 보내지고, 그 후 프로세스가 다시 시작되는 것이 바람직하다.
승인/정산 트랜잭션은 810 EDI 포맷이고, 레벨 Ⅲ 정산 데이터를 포함하는 것이 바람직하다. 고유 트랜잭션 번호, EIPP 생성 매치(EIPP Generated Match), 및 고객 코드 또한 이 트랜잭션의 일부인 것이 바람직하다. 승인/정산 트랜잭션(레벨 Ⅲ)을 위한 데이터는 (a) 인보이스 상에 나타나 있는 데이터 요소, (b) 구매 카드 관련 데이터, 및 (c) MS 게이트웨이(170a) 셋업 정보로부터 획득되는 것이 바람직하다. 승인/정산 트랜잭션은 정규의 시간 구간 동안 추출되어, 일괄 승인/정산 파일에 첨부되는 것이 바람직하다. 백업 파일 또한 갱신되는 것이 바람직하다.
단계 830에서, 소정의 시간 간격에서, 승인/정산 파일은 처리를 위해 EIPP 시스템(120a)을 통해 MS 게이트웨이(170a)에 보내진다. MS 게이트웨이(170a)는 소프트웨어 공급자(120)에 대해 정해진 맵핑 셋업(mapping setup)에 기초하여 승인/정산 파일을 맵핑한다. MS 게이트웨이(170a)는 적합한 매입 플랫폼(appropriate acquired platform)에 대하여 트랜잭션을 식별한다. 이러한 식별에 기초하여, 승인/정산 파일이 나누어지고, 그 후의 처리를 위해 대응 플랫폼에 보내진다. MS 게이트웨이(170a)는 전체 정산 금액의 값에 어떠한 한계를 두기 위해 승인/정산 트랜잭션을 복수의 트랜잭션으로 나눌 수 있다.
단계 840에서, 승인 응답이 MS 게이트웨이(170a)에서 EIPP 시스템(120a)에 되돌려 보내진다. 이 승인 응답은 EIPP 시스템(120a)에 824 EDI 포맷으로 제공된다. 단계 850에서, EIPP 시스템(120a)은 승인 응답 트랜잭션을 수신하고, 개개의 응답 레코드를 평가한다. 응답(실패한 응답 또는 그렇지 않은 응답)에 기초하여, 시스템은 해당 인보이스를 갱신한다. 성공적인 승인이 가능한 곳의 경우, 소프트웨어 공급자(120)로부터 어떠한 추가의 동작이 요구되지 않은 상태에서 MS 게이트 웨이(170a)에 의해 정산 처리가 후속된다. 정산 처리 동안에는 MS 게이트웨이(170a)로부터 아무런 응답이 기대되지 않는다.
승인이 성공적인 경우, 단계 855에서, 인보이스는 승인된 것으로서 플래그되고, 그 상태가 적절하게 갱신된다. 단계 860에서, 인보이스 세부사항 또한 승인의 세부사항과 연관된다. 인보이스 세부사항은 공급자/수취인(130)에게 보여질 수 있는 승인 코드, 트랜잭션 일자 등을 포함한다. 구입자/결제자(110)는 트랜잭션 일자만을 확인할 수 있을 것이다. 고유 트랜잭션 번호, 차변항목(debit)/대변항목(credit) 등을 포함한 결제 레코드의 다른 세부사항 또한 인보이스에 연관될 것이다. 단계 865에서, 특정 인보이스에 대해 승인이 성공적이라는 것을 나타내기 위해 공급자/수취인(130)에게 이메일 통보가 발송된다. 단계 870에서, EIPP XML 파일 관련 트랜잭션이 레코드를 목적으로 생성되어, 필요에 따라 외부로 보내지는 것이 바람직하다.
승인이 성공적이지 않다면, 단계 875에서, 인보이스가 적합하게 플래그되며, 상태가 갱신된다. 단계 880에서, 구입자/결제자(110) 및 공급자/수취인(130)의 에이전트는 이메일을 통해 적절하게 통보된다. 최종적으로, 단계 885에서, 트랜잭션은 적합한 실패 승인 예외 "바스킷"(the appropriate failed authorization exception "basket")에 위치된다.
이하에서는, 본 발명에 따른 MS 승인 실패에 대한 조치(handling)를 행하는 일례의 프로세스에 대한 흐름도를 예시하고 있는 도 9를 참조하여 MS 승인 실패에 대한 조치를 상세하게 설명할 것이다. 단계 905에서, MS 승인 실패 프로세스는, 인보이스 또는 주문 확인서와 연관된 승인 요청이 (ⅰ) MS 게이트웨이 승인 및 정산 프로세스의 일부로서의 MS 게이트웨이(170a)에 의해 거부되거나, 또는 (ⅱ) 수동 승인 및 정산 프로세스의 일부로서의 POS 기기(310)에 의해 거부되는 때에 트리거되는 것이 바람직하다. MS 게이트웨이(170a) 승인 응답을 통해, 또는 MS 게이트웨이(170a)에 의해 매입되지 않은 공급자/수취인(130)의 에이전트에 의한 수동 입력에 의해서, 승인 거부에 대한 이유를 상세하게 나타내는 데이터가 획득될 수도 있다. EIPP 시스템(120a)은 승인 거부 이유를 인보이스 확인서와 연관시키는 것이 바람직하다.
단계 910에서, 인보이스 또는 주문 확인서 상태는 "승인 실패(Authorization Failed)" 상태로 변경된다. 단계 915에서, 특정 인보이스 또는 주문 확인서에 대한 결제 승인이 실패하였다는 것을 알려주기 위해 구입자/결제자(110) 및 공급자/수취인(130)에게 이메일 통보가 발송된다. 단계 920에서, 구입자/결제자(110) 및 공급자/수취인(130)은, 확인하고자 하는 특정 인보이스 또는 주문 확인서의 세부사항을, 인보이스가 "승인 실패"로서 플래그되어 있을 "실패한 승인" 개요 화면으로부터 선택할 수도 있다. 이와 같이 행할 시에, MS 게이트웨이(170a)를 통해 획득되거나 또는 공급자/수취인(130)에 의해 입력되는 거부 이유가, 그 이유를 설명하고 그 거부 이유를 해소하기 위한 지침을 제공하기 위한 추가 정보와 함께, 인보이스 또는 주문 확인서 세부사항 화면의 일부로서 구입자/결제자(110) 및/또는 공급자/수취인(130)에게 제공될 것이다.
"승인 실패" 상태에서의 인보이스 또는 주문 확인서의 세부 화면의 일부로 서, 구입자/결제자(110)는 "그 자체를 다시 제출(Resubmit As-is)" 또는 "결제 방법을 무시(Override Payment Method)" 중의 한 옵션이 제공된다. 구입자 및 공급자는 "승인 실패"에 대한 가능한 이유 및 치유 방안을 찾기 위해 서로 조언하도록 선택할 수도 있다.
단계 925에서, 구입자/결제자(110)는 결제 처리를 위해 특정 인보이스 또는 주문 확인서를 "그 자체를 다시 제출"하도록 선택할 것이다. 이것은 EIPP 시스템(120a) 또는 외부 조언을 통해 획득된 거부 이유가 이러한 방향에 영향을 주는 경우에 발생할 것이다. 단계 930에서, 인보이스 또는 주문 확인서 상태는 그 후에 "결제를 처리" 상태로 변경된다. 공급자/수취인(130)이 MS 게이트웨이(170a)에 의해 매입되었다면, 단계 935에서, MS 게이트웨이(170a) 승인 및 정산 프로시져(procedure)가 호출된다. 공급자/수취인(130)이 MS 게이트웨이(170a)에 의해 매입되지 않았다면, 단계 940에서, 인보이스가 "수동 승인을 대기중"의 상태로 플래그되고, 단계 945에서는 인보이스가 수동 승인을 대기하고 있다는 것을 알려주기 위해 공급자/수취인(130)에게 이메일이 발송되며, 수동 승인 프로세스가 호출된다.
단계 925에서, 구입자/결제자(110)는 인보이스 또는 주문 확인서에 대한 원래의 승인 요청과 연관되어 있는 결제 방법을 무시하도록 선택할 수 있다. 이것은 예컨대 EIPP 시스템(120a)을 통해 또는 외부 조언을 통해 획득된 거부 이유가 이러한 방향에 영향을 주는 경우에 발생할 것이다. "결제 방법을 무시"라는 옵션이 선택되면, 단계 950에서, 구입자/결제자(110)는 대체 결제 방법을 선택하기 위한 화면이 제공되는 것이 바람직하다. 구입자/결제자(110)는 다른 구매 카드를 포함한 임의의 이용 가능한 결제 방법을 연관시키도록 선택할 수 있다. 결제 방법이 선택되면, 단계 955에서는, 구입자/결제자(110)가 처리를 위해 인보이스 또는 주문 확인서를 제출할 것이다. 단계 960에서, 인보이스 또는 주문 확인서 상태는 그 후 "결제 처리" 상태로 변경된다.
단계 950에서, 선택된 결제 방법이 구매 카드가 아닌 경우, 그 처리는 "As-Is" 시스템에서 정해진 바와 같은 방식으로 지속하는 것이 바람직할 것이다. 선택된 결제 방법이 구매 카드인 경우, 그리고 공급자/수취인(130)이 MS 게이트웨이(170a)에 의해 매입되어 있는 경우, 단계 935에서, MS 게이트웨이(170a) 승인 및 정산 처리가 호출될 것이다. 공급자/수취인(130)이 MS 게이트웨이(170a)에 의해 매입되지 않았다면, 단계 940에서, 인보이스는 "수동 승인을 대기중" 상태로 플래그된다. 단계 945에서는, 인보이스가 수동 승인을 대기중이라는 것을 알려주기 위해 공급자/수취인(130)에게 이메일이 발송되며, 그 후 수동 승인 프로세스가 호출된다. 단계 925에서, 인보이스 또는 주문 확인서 거부 세부사항을 확인할 때에, 구입자/수취인(110)은 변경된 PO 트랜잭션을 통해 인보이스와 연관된 구매 카드 정보를 변경하도록 선택할 것이다. 이것은, 예컨대 구입자/수취인(110)이 관련 인보이스 또는 주문 확인서 모두에 반영된 변경내용을 갖기를 원하거나, 또는 구입자/결제자(110)가 선택할 다른 결제 방법이 없는 경우에, 발생할 것이다. 이것은 EIPP 시스템(120a) 내에서 인보이스에 연관되는 PO가 존재하는 경우에만 발생하는 것이 바람직하다.
단계 965에서, 구입자/결제자(110)는 "변경된 PO" 또는 "변경된 구매 카드 정보" 요청을 발행한다. 단계 970에서, PO와 연관된 구매 카드 정보는 그 후 변경된 PO 요청에서의 정보로 갱신된다. 단계 975에서, 그 정보는 인보이스 또는 그 인보이스에 대해 생성되고 아직 "결제된" 상태에 있지 않은 주문 확인서에 전파된다. 단계 980에서, "승인 실패" 상태에 있는 이들 인보이스에 대해, 그 상태가 "결제 처리중" 상태로 리셋된다. 공급자/수취인(130)이 MS 게이트웨이(170a)에 의해 매입되었다면, 단계 935에서, MS 게이트웨이(170a) 승인 및 정산 프로세스가 호출될 것이다. 공급자/수취인(130)이 MS 게이트웨이(170a)에 의해 매입되지 않았다면, 단계 940에서는, 인보이스가 "수동 승인을 대기중" 상태로 플래그된다. 단계 945에서는, 인보이스가 수동 승인을 대기하고 있다는 것을 알려주기 위해 공급자/수취인(130)에게 이메일이 발송되며, 수동 승인 프로세스가 호출된다.
다음의 도표는 승인 및 정산 트랜잭션을 MS 게이트웨이에 발송하기 위해 EDI 810 포맷을 이용하는 방법에 대한 예를 나타내는 것이다.
Figure 112007021716255-PCT00001
Figure 112007021716255-PCT00002
Figure 112007021716255-PCT00003
Figure 112007021716255-PCT00004
Figure 112007021716255-PCT00005
Figure 112007021716255-PCT00006
Figure 112007021716255-PCT00007
Figure 112007021716255-PCT00008
Figure 112007021716255-PCT00009
Figure 112007021716255-PCT00010
Figure 112007021716255-PCT00011
Figure 112007021716255-PCT00012
Figure 112007021716255-PCT00013
Figure 112007021716255-PCT00014
M - Mandatory(강제적)
X - Conditional(조건부)
O - Optional(선택적)
다음의 도표는 승인 응답을 소프트웨어 공급자(170)에게 되돌려주기 위해 MS 게이트웨이(170a)에 의해 EDI 824 포맷이 이용되는 방법에 대한 예를 제공한다. 이 예에서, EDI 997은 요청의 포맷이 적절한지의 여부를 확인응답하기 위해 MS 게이트웨이(170a)에 의해 발송될 것이다.
Figure 112007021716255-PCT00015
Figure 112007021716255-PCT00016
Figure 112007021716255-PCT00017
Figure 112007021716255-PCT00018
Figure 112007021716255-PCT00019
Figure 112007021716255-PCT00020
Figure 112007021716255-PCT00021
Figure 112007021716255-PCT00022
Figure 112007021716255-PCT00023
다음의 도표는 본 발명에 따른 일례의 MS 게이트웨이(170a) 응답/이유 코드를 개략적으로 나타낸다. 다음의 도표에서 "**"는 MS 게이트웨이(170a)에 의해 생성된 응답을 나타낸다.
MS 응답 코드/이유 코드
Figure 112007021716255-PCT00024
Figure 112007021716255-PCT00025
Figure 112007021716255-PCT00026
Figure 112007021716255-PCT00027
본 발명을 특정의 바람직한 실시예를 참조하여 설명하였지만, 본 명세서에 첨부되어 있는 청구범위에 의해 한정되는 바와 같은 본 발명의 기본원리 및 사상을 벗어나지 않는 범위 내에서 당업자에 의한 다양한 수정, 변경 및 대체가 가능함은 자명하다.

Claims (4)

  1. 전자 청구서 결제 및 제시(EIPP: electronic bill payment and presentment) 시스템을 통해 구입자와 공급자 간의 구매 카드 트랜잭션을 시행하는 방법에 있어서,
    상기 구입자의 전사적 자원 관리("ERP" : Enterprise Resource Planning) 시스템에서 상기 구매 카드 트랜잭션에 대한 인보이스를 승인하는 단계;
    상기 구입자의 ERP 시스템에서 결제를 위해 상기 인보이스를 스케쥴링(scheduling)하는 단계;
    상기 트랜잭션에 연관된 고유 트랜잭션 식별자를 포함하는 결제 파일을 상기 구입자의 ERP 시스템으로부터 추출하는 단계;
    고유 트랜잭션 번호를 포함하는 상기 결제 파일을, 결제 승인 및 정산을 위해, 상기 구입자의 ERP 시스템으로부터 매입자(acquirer)에게 발송하는 단계;
    상기 트랜잭션을 기술하고 상기 고유 트랜잭션 식별자를 포함하는 데이터가, 포함된 구매 카드 계산서를, 상기 구입자의 ERP 시스템에 제공하는 단계; 및
    상기 구입자가 상기 트랜잭션을 구매 카드 발급자에게 정산하는 단계
    를 포함하는 구매 카드 트랜잭션의 시행 방법.
  2. 제1항에 있어서,
    상기 고유 트랜잭션 식별자를 포함하는 송금 데이터를, 상기 공급자의 계정 을 조정(conciliation)하기 위해, 상기 공급자에게 제공하는 단계를 더 포함하는, 구매 카드 트랜잭션의 시행 방법.
  3. 전자 청구서 결제 및 제시(EIPP: electronic bill payment and presentment) 시스템을 통해 구입자와 공급자 간의 구매 카드 트랜잭션을 시행하는 방법에 있어서,
    상기 구입자의 전사적 자원 관리("ERP" : Enterprise Resource Planning) 시스템에서 상기 구매 카드 트랜잭션에 대한 인보이스를 승인하는 단계;
    상기 구입자의 ERP 시스템에서 결제를 위해 상기 인보이스를 스케쥴링(scheduling)하는 단계;
    상기 트랜잭션에 연관된 고유 트랜잭션 식별자를 포함하는 결제 파일을 상기 구입자의 ERP 시스템으로부터 추출하는 단계;
    상기 트랜잭션을 기술하고 상기 고유 트랜잭션 식별자를 포함하는 데이터를, 승인 및 정산을 위해 POS(point-of-sale) 기기에 제출하는 단계;
    상기 트랜잭션을 기술하고 상기 고유 트랜잭션 식별자를 포함하는 라인 항목 상세 데이터를, 매칭을 위해 상기 EIPP 시스템으로부터 구매 카드 결제 네트워크에 발송하는 단계;
    상기 트랜잭션을 기술하고 상기 고유 트랜잭션 식별자를 포함하는 데이터가, 포함된 구매 카드 계산서를, 상기 구입자의 ERP 시스템에 제공하는 단계; 및
    상기 구입자가 상기 트랜잭션을 구매 카드 발급자에게 정산하는 단계
    를 포함하는 구매 카드 트랜잭션의 시행 방법.
  4. 제2항에 있어서,
    상기 고유 트랜잭션 식별자를 포함하는 송금 데이터를, 상기 공급자의 계정을 조정하기 위해, 매입자로부터 상기 공급자에게 제공하는 단계를 더 포함하는, 구매 카드 트랜잭션의 시행 방법.
KR1020077006240A 2004-08-25 2005-08-25 자동화된 결제 승인 및 정산을 위한 방법 및 시스템 KR20070044496A (ko)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US60421504P 2004-08-25 2004-08-25
US60/604,215 2004-08-25
US62365604P 2004-10-29 2004-10-29
US60/623,656 2004-10-29

Publications (1)

Publication Number Publication Date
KR20070044496A true KR20070044496A (ko) 2007-04-27

Family

ID=36000604

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020077006240A KR20070044496A (ko) 2004-08-25 2005-08-25 자동화된 결제 승인 및 정산을 위한 방법 및 시스템

Country Status (9)

Country Link
US (2) US20080033878A1 (ko)
EP (1) EP1810237A4 (ko)
JP (1) JP2008511085A (ko)
KR (1) KR20070044496A (ko)
AU (1) AU2005280100A1 (ko)
CA (1) CA2577271A1 (ko)
IL (1) IL181401A0 (ko)
MX (1) MX2007002075A (ko)
WO (1) WO2006026418A2 (ko)

Families Citing this family (85)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7610244B2 (en) * 2001-01-17 2009-10-27 Xprt Ventures, Llc System and method for effecting payment for an item offered for an electronic auction sale
US7483856B2 (en) 2001-01-17 2009-01-27 Xprt Ventures, Llc System and method for effecting payment for an electronic auction commerce transaction
US7627528B2 (en) * 2001-01-17 2009-12-01 Xprt Ventures, Llc System and method for effecting a real-time payment for an item won on an electronic auction
EP1504393A4 (en) 2002-04-23 2008-03-19 Clearing House Service Company PAYMENT IDENTIFICATION CODE AND PAYMENT SYSTEM THEREWITH
US20060093589A1 (en) * 2004-02-19 2006-05-04 Warrington Kenneth H Vp2-modified raav vector compositions and uses therefor
US7693783B2 (en) 2002-06-12 2010-04-06 Cardinalcommerce Corporation Universal merchant platform for payment authentication
US8645266B2 (en) * 2002-06-12 2014-02-04 Cardinalcommerce Corporation Universal merchant platform for payment authentication
US8725607B2 (en) 2004-01-30 2014-05-13 The Clearing House Payments Company LLC Electronic payment clearing and check image exchange systems and methods
US11308477B2 (en) 2005-04-26 2022-04-19 Spriv Llc Method of reducing fraud in on-line transactions
US11818287B2 (en) 2017-10-19 2023-11-14 Spriv Llc Method and system for monitoring and validating electronic transactions
US10181149B1 (en) * 2006-03-06 2019-01-15 Versata, Inc. Electronic processing of invoices with no purchase orders
US10176509B1 (en) * 2006-03-06 2019-01-08 Versata, Inc. Flexible and integrated electronic processing of different invoice categories
US8775277B2 (en) 2006-04-21 2014-07-08 International Business Machines Corporation Method, system, and program product for electronically validating invoices
US7726561B2 (en) * 2006-07-21 2010-06-01 Intuit Inc. System and method for reconciling credit card payments with corresponding transactions
GB2442759A (en) * 2006-10-13 2008-04-16 Microsoft Corp Reconciliation of batch payments
US11354667B2 (en) 2007-05-29 2022-06-07 Spriv Llc Method for internet user authentication
US20110270720A1 (en) * 2007-09-07 2011-11-03 Manohar Enterprises, Inc. Bank balance funds check and negative balance controls for enterprise resource planning systems
US8407141B2 (en) * 2007-10-30 2013-03-26 Visa U.S.A. Inc. System and method for processing multiple methods of payment
US8311913B2 (en) * 2007-10-30 2012-11-13 Visa U.S.A. Inc. Payment entity account set up for multiple payment methods
US8311937B2 (en) * 2007-10-30 2012-11-13 Visa U.S.A. Inc. Client supported multiple payment methods system
US8374932B2 (en) * 2007-10-30 2013-02-12 Visa U.S.A. Inc. Payment entity device transaction processing using multiple payment methods
US8311914B2 (en) 2007-10-30 2012-11-13 Visa U.S.A. Inc. Payment entity for account payables processing using multiple payment methods
US8341046B2 (en) * 2007-10-30 2012-12-25 Visa U.S.A. Inc. Payment entity device reconciliation for multiple payment methods
US10043201B2 (en) 2008-01-31 2018-08-07 Bill.Com, Inc. Enhanced invitation process for electronic billing and payment system
US10769686B2 (en) 2008-01-31 2020-09-08 Bill.Com Llc Enhanced invitation process for electronic billing and payment system
US9141991B2 (en) * 2008-01-31 2015-09-22 Bill.Com, Inc. Enhanced electronic data and metadata interchange system and process for electronic billing and payment system
US8799814B1 (en) 2008-02-22 2014-08-05 Amazon Technologies, Inc. Automated targeting of content components
WO2009149164A2 (en) * 2008-06-03 2009-12-10 Cardinalcommerce Corporation Alternative payment implementation for electronic retailers
US8762210B2 (en) 2008-06-03 2014-06-24 Cardinalcommerce Corporation Alternative payment implementation for electronic retailers
US10157375B2 (en) * 2008-06-03 2018-12-18 Cardinalcommerce Corporation Alternative payment implementation for electronic retailers
US9704161B1 (en) 2008-06-27 2017-07-11 Amazon Technologies, Inc. Providing information without authentication
US9449319B1 (en) 2008-06-30 2016-09-20 Amazon Technologies, Inc. Conducting transactions with dynamic passwords
US8788945B1 (en) 2008-06-30 2014-07-22 Amazon Technologies, Inc. Automatic approval
US8295898B2 (en) * 2008-07-22 2012-10-23 Bank Of America Corporation Location based authentication of mobile device transactions
US10970777B2 (en) 2008-09-15 2021-04-06 Mastercard International Incorporated Apparatus and method for bill payment card enrollment
US11792314B2 (en) 2010-03-28 2023-10-17 Spriv Llc Methods for acquiring an internet user's consent to be located and for authenticating the location information
US8590779B2 (en) 2010-06-29 2013-11-26 Visa International Service Association Value token conversion
US11978052B2 (en) 2011-03-28 2024-05-07 Spriv Llc Method for validating electronic transactions
US8635156B2 (en) * 2011-09-06 2014-01-21 Rawllin International Inc. Converting paper invoice to electronic form for processing of electronic payment thereof
JP2013089128A (ja) * 2011-10-20 2013-05-13 Isi Corp プリペイドカードシステム
US8819789B2 (en) 2012-03-07 2014-08-26 Bill.Com, Inc. Method and system for using social networks to verify entity affiliations and identities
FR3001816B1 (fr) * 2013-02-05 2015-03-06 Thales Sa Systeme de processeur multi-utilisateurs de traitement d'informations
US10115137B2 (en) 2013-03-14 2018-10-30 Bill.Com, Inc. System and method for enhanced access and control for connecting entities and effecting payments in a commercially oriented entity network
US10417674B2 (en) 2013-03-14 2019-09-17 Bill.Com, Llc System and method for sharing transaction information by object tracking of inter-entity transactions and news streams
US10410191B2 (en) 2013-03-14 2019-09-10 Bill.Com, Llc System and method for scanning and processing of payment documentation in an integrated partner platform
US9299049B2 (en) * 2013-03-15 2016-03-29 Sap Se Contract-based process integration
US10572921B2 (en) 2013-07-03 2020-02-25 Bill.Com, Llc System and method for enhanced access and control for connecting entities and effecting payments in a commercially oriented entity network
US9519934B2 (en) 2013-07-19 2016-12-13 Bank Of America Corporation Restricted access to online banking
US9646342B2 (en) 2013-07-19 2017-05-09 Bank Of America Corporation Remote control for online banking
US11663599B1 (en) 2014-04-30 2023-05-30 Wells Fargo Bank, N.A. Mobile wallet authentication systems and methods
US10997592B1 (en) 2014-04-30 2021-05-04 Wells Fargo Bank, N.A. Mobile wallet account balance systems and methods
US11288660B1 (en) 2014-04-30 2022-03-29 Wells Fargo Bank, N.A. Mobile wallet account balance systems and methods
US11748736B1 (en) 2014-04-30 2023-09-05 Wells Fargo Bank, N.A. Mobile wallet integration within mobile banking
US11461766B1 (en) 2014-04-30 2022-10-04 Wells Fargo Bank, N.A. Mobile wallet using tokenized card systems and methods
US11610197B1 (en) 2014-04-30 2023-03-21 Wells Fargo Bank, N.A. Mobile wallet rewards redemption systems and methods
US9652770B1 (en) 2014-04-30 2017-05-16 Wells Fargo Bank, N.A. Mobile wallet using tokenized card systems and methods
US10445739B1 (en) 2014-08-14 2019-10-15 Wells Fargo Bank, N.A. Use limitations for secondary users of financial accounts
US11295308B1 (en) 2014-10-29 2022-04-05 The Clearing House Payments Company, L.L.C. Secure payment processing
US11853919B1 (en) 2015-03-04 2023-12-26 Wells Fargo Bank, N.A. Systems and methods for peer-to-peer funds requests
US11023888B2 (en) * 2015-06-09 2021-06-01 Worldpay, Llc Systems and methods for management and recycling of payment transactions
US11694168B2 (en) 2015-07-01 2023-07-04 The Clearing House Payments Company L.L.C. Real-time payment system, method, apparatus, and computer program
US11042882B2 (en) 2015-07-01 2021-06-22 The Clearing House Payments Company, L.L.C. Real-time payment system, method, apparatus, and computer program
US9474042B1 (en) * 2015-09-16 2016-10-18 Ivani, LLC Detecting location within a network
US11533584B2 (en) 2015-09-16 2022-12-20 Ivani, LLC Blockchain systems and methods for confirming presence
US20170193469A1 (en) * 2015-12-31 2017-07-06 Mastercard International Incorporated Method and system for providing e-invoices
US11438412B2 (en) * 2016-01-07 2022-09-06 Worldpay, Llc Technologies for conversion of mainframe files for big data ingestion
EP3485604B1 (en) 2016-07-15 2020-05-20 CardinalCommerce Corporation Authentication to authorization bridge using enriched messages
US11468414B1 (en) 2016-10-03 2022-10-11 Wells Fargo Bank, N.A. Systems and methods for establishing a pull payment relationship
CN113112254A (zh) * 2016-11-11 2021-07-13 创新先进技术有限公司 一种区域消息共享方法及装置
US11295297B1 (en) 2018-02-26 2022-04-05 Wells Fargo Bank, N.A. Systems and methods for pushing usable objects and third-party provisioning to a mobile wallet
US11436577B2 (en) 2018-05-03 2022-09-06 The Clearing House Payments Company L.L.C. Bill pay service with federated directory model support
US11074577B1 (en) 2018-05-10 2021-07-27 Wells Fargo Bank, N.A. Systems and methods for making person-to-person payments via mobile client application
US11775955B1 (en) 2018-05-10 2023-10-03 Wells Fargo Bank, N.A. Systems and methods for making person-to-person payments via mobile client application
US20200034788A1 (en) * 2018-07-24 2020-01-30 Eugenio S. YNION, JR. Method, system, apparatus, and program for real-time and online freight management
US11615407B2 (en) 2019-02-15 2023-03-28 Highradius Corporation Touchless virtual card payment automation
US11282069B2 (en) * 2019-02-15 2022-03-22 Highradius Corporation Touchless virtual card payment automation
US11551190B1 (en) 2019-06-03 2023-01-10 Wells Fargo Bank, N.A. Instant network cash transfer at point of sale
US11257134B2 (en) 2019-06-28 2022-02-22 American Express Travel Related Services, Inc. Supplier invoice reconciliation and payment using event driven platform
CN111815446A (zh) * 2020-07-06 2020-10-23 泰康保险集团股份有限公司 一种电子交易方法、系统及存储介质
JP7239669B2 (ja) * 2020-12-21 2023-03-14 ペイトナー株式会社 買掛金を管理するための装置、方法及びプログラム
US11763395B2 (en) 2021-01-27 2023-09-19 Coupa Software Incorporated Duplicate invoice detection and management
WO2023288256A1 (en) * 2021-07-15 2023-01-19 Woje, Inc. Value transfer processing plans
US11995621B1 (en) 2021-10-22 2024-05-28 Wells Fargo Bank, N.A. Systems and methods for native, non-native, and hybrid registration and use of tags for real-time services
WO2023091364A1 (en) * 2021-11-16 2023-05-25 Mastercard International Incorporated Method and system of enterprise resource planning
US20240029073A1 (en) * 2022-07-21 2024-01-25 Mastercard International Incorporated Method and system of facilitating payments through an intermediary platform

Family Cites Families (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6006199A (en) * 1991-12-31 1999-12-21 International Business Machines Corporation Method and system for automated payment within a computer integrated manufacturing system
US5384449A (en) * 1992-04-28 1995-01-24 Visa International Service Association Authorization matching system
US6658568B1 (en) * 1995-02-13 2003-12-02 Intertrust Technologies Corporation Trusted infrastructure support system, methods and techniques for secure electronic commerce transaction and rights management
US5850442A (en) * 1996-03-26 1998-12-15 Entegrity Solutions Corporation Secure world wide electronic commerce over an open network
US6044362A (en) * 1997-09-08 2000-03-28 Neely; R. Alan Electronic invoicing and payment system
US6134594A (en) * 1997-10-28 2000-10-17 Microsoft Corporation Multi-user, multiple tier distributed application architecture with single-user access control of middle tier objects
US6098053A (en) * 1998-01-28 2000-08-01 Citibank, N.A. System and method for performing an electronic financial transaction
US7451114B1 (en) * 1999-02-19 2008-11-11 Visa International Service Association Conducting commerce between individuals
US6609113B1 (en) * 1999-05-03 2003-08-19 The Chase Manhattan Bank Method and system for processing internet payments using the electronic funds transfer network
WO2001031052A1 (en) * 1999-10-25 2001-05-03 Colorado Coagulation Consultants Thromboxane b2 metabolite and methods for regulating aspirin-related platelet action
US6629081B1 (en) * 1999-12-22 2003-09-30 Accenture Llp Account settlement and financing in an e-commerce environment
US6850900B1 (en) * 2000-06-19 2005-02-01 Gary W. Hare Full service secure commercial electronic marketplace
US6882986B1 (en) * 2000-08-07 2005-04-19 Tymetrix Method for automatic processing of invoices
JP2002109409A (ja) * 2000-09-29 2002-04-12 Fujitsu Ltd 電子商取引システムにおける電子商取引方法
US20020052841A1 (en) * 2000-10-27 2002-05-02 Guthrie Paul D. Electronic payment system
US7318049B2 (en) * 2000-11-17 2008-01-08 Gregory Fx Iannacci System and method for an automated benefit recognition, acquisition, value exchange, and transaction settlement system using multivariable linear and nonlinear modeling
US20020069093A1 (en) * 2000-12-04 2002-06-06 Stanfield Richard C. Electronic reservation referral system and method
US20020123938A1 (en) * 2001-03-01 2002-09-05 Yu Philip S. Systems and methods to facilitate a transaction wherein a purchaser is associated with an approver
US20020147656A1 (en) * 2001-04-04 2002-10-10 Tam Richard K. E-commerce using a catalog
US20020184116A1 (en) * 2001-04-04 2002-12-05 Iuniverse.Com Data structure for holding product information
EP1265202A1 (en) * 2001-06-04 2002-12-11 Orbis Patents Limited Business-to-business commerce using financial transaction numbers
US20030093373A1 (en) * 2001-11-13 2003-05-15 Smirnoff Kellie M. Systems and methods for providing invoice-based billing information associated with a credit card transaction
US20100030675A1 (en) * 2001-12-06 2010-02-04 Hanan Christopher C Payor focused business to business electronic invoice presentment and accounts payable reconciliation system and method
US20030110128A1 (en) * 2001-12-07 2003-06-12 Pitney Bowes Incorporated Method and system for importing invoice data into accounting and payment programs
US20030220863A1 (en) * 2002-05-24 2003-11-27 Don Holm System and method for varying electronic settlements between buyers and suppliers with dynamic discount terms
WO2003107145A2 (en) * 2002-06-18 2003-12-24 Mastercard International Incorporated System and method for integrated electronic invoice presentment and payment
JP4624354B2 (ja) * 2003-09-10 2011-02-02 ミュージックマッチ インコーポレイテッド 音楽購入及び再生のシステム及び方法
US20050096967A1 (en) * 2003-10-31 2005-05-05 Gerrits Kevin G. Method and apparatus for processing of purchase orders
US8554673B2 (en) * 2004-06-17 2013-10-08 Jpmorgan Chase Bank, N.A. Methods and systems for discounts management

Also Published As

Publication number Publication date
US20080033878A1 (en) 2008-02-07
CA2577271A1 (en) 2006-03-09
JP2008511085A (ja) 2008-04-10
MX2007002075A (es) 2007-04-24
WO2006026418A2 (en) 2006-03-09
US20090276321A1 (en) 2009-11-05
IL181401A0 (en) 2007-07-04
AU2005280100A1 (en) 2006-03-09
EP1810237A4 (en) 2012-05-02
WO2006026418A3 (en) 2006-05-04
EP1810237A2 (en) 2007-07-25

Similar Documents

Publication Publication Date Title
KR20070044496A (ko) 자동화된 결제 승인 및 정산을 위한 방법 및 시스템
US7676434B2 (en) Payer direct hub
AU2009200961B2 (en) Method and system for conducting a commercial transaction between a buyer and a seller
US8615457B2 (en) Payment entity device reconciliation for multiple payment methods
US7941352B2 (en) System and method for providing dispute resolution for electronic payment transactions
US8571978B2 (en) Method and system for providing assurance and financing services
US8108296B2 (en) System and method for varying electronic settlements between buyers and suppliers with dynamic discount terms
US8732044B2 (en) Electronic transaction apparatus and method
US8458086B2 (en) Allocating partial payment of a transaction amount using an allocation rule
JP5188505B2 (ja) 支払処理システム債務転換通知
US20140136412A1 (en) Least cost routing interchange for b2b purchase card payments
AU2002340294A1 (en) Method and system for conducting a commercial transaction between a buyer and a seller
US20240037513A1 (en) Payment processing method and apparatus using an intermediary platform
AU2012200011B2 (en) Method and system for automated payment authorization and settlement
US11810076B1 (en) Payment processing method and apparatus using an intermediary platform
KR20070050038A (ko) 보증 및 금융 서비스를 제공하는 방법 및 시스템

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
AMND Amendment
E601 Decision to refuse application
J201 Request for trial against refusal decision
A107 Divisional application of patent
AMND Amendment
B601 Maintenance of original decision after re-examination before a trial
J301 Trial decision

Free format text: TRIAL DECISION FOR APPEAL AGAINST DECISION TO DECLINE REFUSAL REQUESTED 20120709

Effective date: 20140224