요약

  • RFC 3538은 IOTP 브리지 내에서 연속적인 SET 메시지가 생성되거나 처리될 때 20, 40, 60, 80, 100을 할당했다. 이 숫자들은 인터페이스 진행 상황을 나타냈을 뿐 상거래 완료의 비율은 아니었다.
  • 100 단계에서PRes는 승인된 인가 또는 성공한 캡처를 보고할 수 있었으며,CompletedOK는 취소 이후Failed로 바뀔 수 있었다. 한편 정산과 실물 배송은 이 계량기의 입증 범위 밖에 있었다.

오른쪽 끝에 안심시키는 막대가 하나 놓인 운영 콘솔을 상상해 보자. 고객은 결제 화면을 통과했고, 결제 처리기는 응답했으며, 화면에는 완료라고 표시되어 있다. 이제 어떤 명제가 참인가? 요청이 인가되었다는 것인가? 값이 캡처되었다는 것인가? 은행들이 정산했다는 것인가? 창고가 물품을 출고했다는 것인가? 아무도 취소할 수 없다는 것인가? RFC 3538의 답은 덜 극적이면서 더 유용했다. SET-IOTP 브리지가 매핑된 마지막 메시지를 처리했다는 것뿐이다.

2003년 6월 Informational로 발표된 RFC 3538은 Internet Open Trading Protocol 버전 1.0을 보완했다. IOTP는 전자상거래에 공통 프레임워크를 제공하면서 특정 결제 시스템이 결제 API를 통해 통과하도록 하려 했다. 이 보완 문서는 Secure Electronic Transaction 메시지가 그 인터페이스에 어떻게 맞는지를 기술했다. 이 RFC의 역사적 중요성은 SET/IOTP가 상거래를 장악했다는 증명이 아니다. 동결된 기록에는 명시된 배포 사례도 채용 척도도 없다. 중요한 것은 겉보기에 최종적인 상태가 자신의 메커니즘에 국한되도록 다룬 그 세심함이다.

8.12절이 가장 깔끔한 다이어그램을 제공한다. 첫 SET Initiation Response가 생성되거나 처리된 후PercentComplete는 20이 된다.PinitReq는 40,PinitRes는 60,PReq는 80,PRes는 100에 대응한다. 소비자와 결제 처리기는 생성과 처리를 서로 반대 방향에서 관찰한다. 첫 시작 단계에는 가변 개수의 메시지가 포함될 수 있지만, 첫 응답은 여전히 20을 받는다. 이는 스톱워치도, 동등한 작업량의 측정도 아니다. 인터페이스 설계자의 랜드마크 서열이다.

마지막 랜드마크의 의미는 의도적으로 복수적이다. 브리지가PRes를 처리할 때 한 성공 사례는 승인된 인가 코드를 동반한authorizationPerformed이고, 다른 사례는 성공한 캡처 코드를 동반한capturePerformed이다. 인가와 캡처는 동의어가 아니다. 진행 허가와 이후의 수금 작업은 서로 다른 상거래 시점을 점유한다. 따라서 동일한 봉투 유형과 동일한 100 값이 서로 다른 두 여정을 닫을 수 있다.

상태 머신은 더 나아가 '최종'이라는 언어의 유혹을 거부한다. 결제 처리기 측에서 진행 중인 트랜잭션은CompletedOK에 도달할 수 있다. 그러나 RFC 3538은 상태 변경 또는 취소 작업이 결제를 취소할 때CompletedOK가Failed로 이동할 수 있음을 명시적으로 허용한다. '완료'는 기록된 시점에서 범위가 지정된 상태일 뿐, 형이상학적 보장이 아니다. 전환 이력을 버리는 시스템은 되돌릴 수 있는 체크포인트를 가공된 최종성으로 바꾸어 버린다.

수취 확인 처리는 더 날카로운 경고를 제공한다.CheckPayReceipt함수는 Payment Receipt Information를 특별히 확인하지 않는다. 요청 메시지가 유효하기만 하면 일반 응답을 보낸다. API 계약으로서는 완벽하게 옳을 수 있다. 오직 어떤 제품이 구문적 수용을 상거래 검증으로 이름을 바꿀 때만 오해의 소지가 생긴다. 유효한 봉투, 인식된 수취 컨테이너, 검증된 기저 주장은 서로 다른 세 종류의 수취다.

배송은 결제 브리지 너머에 있다. 실물 상품의 경우 이 문서는 IOTP Delivery Exchange를 생략할 것을 권한다. 배송 조회 위치를 지정할 수 있으며, 처리기 간 신용 인가에 대한 조회는 IOTP 밖에서 이루어질 수 있다. 디지털 상품의 경우 인가는 실시간으로 처리해야 한다. 이러한 선택은 책임의 경계를 그린다. 완료된 결제 메시지 경로는 소포를 옮기지도, 다운로드가 독자에게 도달했음을 입증하지도 않는다.

조회와 오류 처리도 유사한 구분을 유지한다. SET Inquiry Initiation은 생략되며, 요청과 응답 메시지는 IOTP 결제 스킴 데이터에 내장된다. 브리지의 기술 오류는HardError를 사용하고, 비즈니스 실패는PRes상태를 포함한 별도의 경로로 보고된다. 운영자는 어느 계층이 오류를 발생시켰는지를 유지해야 한다. 그렇지 않으면 전달 가능한 비즈니스 거절이 고장 난 브리지처럼 보이거나, 기술적으로 정상인 브리지가 성공한 판매처럼 보일 수 있다.

이 경계는 IOTP v2 요구사항과 상거래 인가 대비 구성을 다루는 보존된 RFC 3354의 역사, 그리고 수정된 IOTP 문법, 신원, 조회, 넓은 결제/정산/배송 분리를 다루는 RFC 3504의 역사와는 다르다. RFC 3538이 기여하는 것은 구체적인 계기판이다. 다섯 숫자의 사다리, 이중 용도의 마지막 메시지, 완료 이후의 취소 엣지다.

남는 설계 규칙은 단순하다. 모든 진행률 표시에는 명명된 분모가 필요하다. 생성 또는 처리된 정확한 메시지, 그것을 관찰한 행위자, 그 안의 완료 코드, 그리고 이후의 모든 상태 전환을 기록하라. 그러면 꽉 찬 막대가 유용한 증거가 된다. 그 출처가 없다면 100은 자신이 결코 측정하지 않은 사건들로부터 확신을 빌릴 수 있는 단지 하나의 형상일 뿐이다.

출처