시작 전에
동일한 고객에 대해 준비된 페이인 케이퍼빌리티와 준비된 발급 목적지 지갑이 필요해요. 열린 작업은 케이퍼빌리티와 태스크를 통해 완료한 뒤 두 리소스를 모두 다시 조회하세요.1. 견적 생성
POST /v3/quotes로 가격을 생성하세요. 다음 헤더를 보내세요:
data.id를 QUOTE_ID로 저장하세요. 환율에서 재계산하지 말고 반환된 금액과 수수료를 표시하세요.
2. 견적 실행
만료 전에POST /v3/transfers로 현재 견적을 실행하세요. 의도한 이 전송에 새 키를 사용하세요:
data.id를 TRANSFER_ID로 저장하고 현재 상태를 유지하세요.
카드 및 Apple Pay용 리턴 URL 추가
카드 또는 Apple Pay 견적의 경우 동일한 요청에 선택 사항인redirectUrl을 포함할 수 있어요. 고객이 호스팅된 체크아웃을 마치면 체크아웃 페이지가 이 URL을 열어 고객을 앱으로 다시 데려가요.
redirectUrl은 최대 2048자의 절대 HTTPS URL이어야 하며 자격 증명을 포함해서는 안 돼요. 리턴 내비게이션을 지원하지 않는 견적에 redirectUrl을 보내면 무시되는 대신 유효성 검사에 실패해요.
redirectUrl에 도달하는 것은 브라우저 내비게이션일 뿐이에요. 결제나 전송이 완료되었음을 확인해 주지 않아요. 완료 여부는 4단계의 전송 상태와 웹훅 이벤트로 판단하세요.
카드 견적의 체크아웃 방식 미리 선택
카드 견적의 경우 동일한 요청에 선택 사항인checkoutMethod를 포함해 호스팅된 체크아웃이 어떤 결제 옵션으로 열릴지 고를 수 있어요. 현재 값은 card, apple_pay, google_pay, cash_app, sepa, blik이에요. 이 목록은 열려 있고 늘어날 수 있으므로 전송 조회에서 모르는 값도 허용하세요. 요청한 방식이 고객과 고객의 기기에서 사용 가능하면 체크아웃이 그 방식으로 열리고, 고객은 체크아웃이 제공하는 다른 방식도 여전히 선택할 수 있어요. 생략하면 기본 미리 선택이 유지돼요.
checkoutMethod는 선호 방식일 뿐 보장은 아니에요. 사용 가능 여부는 고객, 고객의 기기, 체크아웃에 따라 달라지므로 방식을 요청한다고 해서 사용 가능해지지는 않아요. 여기서 sepa와 blik은 카드 체크아웃 내부의 결제 옵션이지 Swipelux의 기능, 레일, 계좌가 아니에요. 미리 선택은 견적의 기능, 금액, 수수료를 바꾸지 않으며 최종 수수료는 체크아웃에서 확인돼요. 전송 조회는 요청한 값을 그대로 돌려주지만 고객이 실제로 사용한 방식을 확인해 주지는 않아요. 카드 견적이 아닌 견적에 checkoutMethod를 보내면 무시되는 대신 유효성 검사에 실패하고, 같은 멱등성 키로 재전송할 때는 같은 checkoutMethod를 보내야 해요.
3. 자금 조달 지침 조회
GET /v3/transfers/{transferId}/instructions를 조회하세요. 반환된 data.instructions 변형을 유형을 가정하지 않고 렌더링하세요.
이 정보는 전송별 정보예요. 한 전송의 은행 좌표, 코드, 호스팅된 URL, 금액, 참조 또는 만료를 다른 페이인에 재사용하지 마세요.
은행 지침의 경우 reference.required가 true이면 은행 좌표 옆에 정확한 reference.value를 표시하고 복사 가능하게 만드세요. 동일한 지침 세트에서 반환된 금액과 통화를 표시하세요.
발급 은행 계좌는 달라요. 이후 입금을 위한 재사용 가능한 정보를 제공해요. 그것이 의도한 경험이라면 은행 계좌 발급을 참고하세요.
4. 정산 추적
실행 후 그리고 각 이벤트 이후에GET /v3/transfers/{transferId}를 조회하세요. 최신 data.state에서 고객에게 표시되는 상태를 이끌어내세요.
전송에 다른 작업이 필요하면 data.stateDetail과 data.openTaskIds를 사용하세요. 예상 스케줄로 완료로 표시하지 마세요.
다음으로 웹훅을 추가하고, 제품이 처리하는 결과에 도달할 때까지 전송 상태를 동기화된 상태로 유지하세요.