Payment Abstractions

PG 를 통해 결제를 하기 위해서 빌링 프레임워크는 크게 두 가지의 API 를 가지고있어야 한다.

• 반복 청구를위한 지불 및 환불 API
• 일회성 비용을위한 직접 지불 API

반복 청구를위한 지불 및 환불 API 는 빌링 프레임워크 엔진에서 구독료를 청구하고, 해당 구독과 관련된 인보이스 및 지불에 대한 환불, 지불 거절, 조정 등을 처리한다.

일회성 비용을위한 직접 지불 API는 전자 상거래 애플리케이션 (예 : 장바구니)에서 결제 (인증, 캡처, 크레딧, 환불 등)를 트리거하는 데 사용될 수 있다. 또한 호스팅 된 지불 페이지의 경우 지불 양식을 작성하고 URL을 리디렉션하는 도우미를 제공해야 한다. 단, 모든 구독 또는 인보이스와 독립적이며 결제에만 사용된다는 점이 틀리다.

빌링 프레임워크는 청구 및 지불 인프라를 구축하기 위한 플랫폼이므로, 특정 지불 게이트웨이에 종속되지 않아야 한다. 다수의 PG API 를 사용할 수 있도록 PG 플러그인을 등록할 수 있는 시스템이 되어야 한다. PG 플러그인은 특정 게이트웨이의 API 를 구현한다.

Payment States

거의 모든 PG 사는 승인, 구매, Direct 신용카드 구매, 캡쳐, 환불 API 를 제공하고 있다. 이에 따라 빌링 프레임워크의 각 PG 플러그인은 획일화된 Status 로 PG 사의 API 결과를 제어해야 한다.

초기 지불시에, 클라이언트는 승인, 구매 또는 신용카드 구매중 하나를 수행해야 한다. (환불과 같은 다른 모든 작업에는 초기 지불이 필요다). 초기 지불 호출은 지불 명령 및 초기 PaymentTransaction을 작성합니. 그런 다음 사용자는 동일한 지불 (캡처, 환불 등)에 대한 추가 요청을 제출할 수 있으며 각 호출은 동일한 지불에 추가 PaymentTransaction을 부여함으로써 이루어진다. 지불후에 가능한 후속 작업을 추진할 수있는 Status 를 정의해야 하는데, 예를 들어, 상태 AUTH_SUCCESS의 지불에 대해 캡처 호출을 수행 할 수 있지만 AUTH_ERRORED 상태의 지불에 대해서는 이러한 조작을 수행 할 수 없다. 다음 다이어그램은 플러그인 Status 전환에 대한 예시이다.

plugin result	payment transaction status	payment state	description
PROCESSED	SUCCESS	{AUTH,CAPTURE,..}_SUCCESS	The payment transaction went through and was successful
PENDING	PENDING	{AUTH,CAPTURE,..}_PENDING	Successful asynchronous operation (e.g. ACH transfer) or multi-step call (e.g. 3D-Secure authorization)
ERROR	PAYMENT_FAILURE	{AUTH,CAPTURE,..}_FAILED	The payment transaction went through but failed (e.g insufficient funds)
CANCELED	PLUGIN_FAILURE	{AUTH,CAPTURE,..}_ERRORED	The payment transaction did not happen (e.g unable to connect to the provider)
UNDEFINED, timeout or any exception	UNKNOWN	{AUTH,CAPTURE,..}_ERRORED	The payment transaction may or not have succeeded, manual review needed

첫 번째 3 건은 일반적인 경우이지만 마지막 2 건은 사용자가 지급 작업을 수행 할 수 없다는 오류이다.

CANCELED 결과 코드의 경우 사용자가 지불을 거절한 경우 게이트웨이가 작동하지 않아 지불이 시도되지 않았으므로 해결할 시도가 없다.

타임 아웃 또는 UNDEFINED 결과 코드의 경우 작업이 실제로 완료되었을 수도 있다. 빌링 프레임워크는 백그라운드 작업을 실행하여 해당 사례를 탐지하고 플러그인(PG)에 쿼리하여 상태가 실제로 알려 졌는지 확인한 후 트랜잭션 상태를 업데이트하고 지불을 적절한 상태로 변경해야 한다.

플러그인이 지불이 완료되었는지 여부를 알 수없는 경우 트랜잭션은 알 수 없음 상태로 유지된다. 이 경우는 고객과 분란의 여지가 될 수 있음으로 상시 모니터링을 통해 문제를 해결하고 데이터를 적절하게 수정하는 것이 좋다 (예 : 게이트웨이의 상태를 수동으로 확인).

중요한것은, 지불 결제 시스템의 특성상 모든 Status 가 항상 좋은 상태에 있을 수는 없으며, 관리자의 수동으로 해결해야 할 일이 반드시 생긴다는 것이다.