클라이언트가 잘못된 링크를 보낸 경우 API 주문 취소

먼저 주문이 공급업체에 전달되었는지 확인하세요

잘못된 링크가 항상 프로모션이 이미 시작되었다는 것을 의미하지는 않습니다. 자체 데이터베이스에서 주문이 생성되었지만 아직 API로 전송되지 않았을 수 있습니다. 이 경우 취소는 전적으로 귀하의 처리 로직에 달려 있습니다: 주문을 취소로 표시하고 자동 결제를 중단하며 전송을 시작하지 않으면 됩니다.

주문 ID, 생성 시간, 링크, 서비스 유형 및 API 요청 로그를 확인하세요. 공급업체로의 요청이 전송되지 않았다면 기존 주문 위에 새 주문을 만들지 마세요. 먼저 원래 요청의 취소를 기록해야 합니다. 그렇지 않으면 클라이언트가 서로 다른 링크에 대해 두 번의 실행을 받을 수 있습니다.

공급업체의 주문 상태를 확인하세요

API 요청이 이미 전송되었다면 공급업체에 현재 상태를 요청하세요. 상태 이름은 다르지만 일반적으로 대기, 처리, 부분 완료, 완료 및 취소의 여러 그룹으로 나눌 수 있습니다. 결정을 내리는 데 중요한 것은 귀하의 패널 상태가 아니라 서비스를 실행하는 측의 응답입니다.

• 대기: 주문이 아직 취소를 허용할 수 있습니다.
• 처리: 중단이 때때로 가능하지만 일부 볼륨은 이미 시작되었을 수 있습니다.
• 부분 완료: 공급업체가 이러한 작업을 지원하는 경우 남은 부분만 취소할 수 있습니다.
• 완료: 취소로 링크를 수정할 수 없습니다.

내부 상태만 확인하는 것의 단점은 지연되어 업데이트될 수 있다는 것입니다. 마지막 API 응답과 수신 시간을 기준으로 하세요.

서비스 시작 전에 주문을 취소하세요

대기 중인 주문의 경우 공급업체 문서에 명시된 경우 취소 방법을 사용하세요. 내부 번호가 다른 값인 경우 주문 생성 시 받은 ID를 전달하세요. 작업 코드, 상태, 오류 텍스트 및 요청 시간을 포함한 전체 응답을 저장하세요.

API가 취소를 확인할 때까지 주문이 취소되었다고 간주하지 마세요. 요청 수락 응답과 실제 서비스 중단은 다른 이벤트일 수 있습니다. 일부 통합에서는 먼저 수락 확인이 오고 최종 상태는 나중에 변경됩니다.

이 옵션의 단점은 공급업체가 주문을 처리에서 제거할 시간이 없을 수 있다는 것입니다. 그러면 취소가 거부를 반환하거나 미실행 부분에만 적용됩니다.

확인 없이 이미 생성된 주문의 링크를 변경하지 마세요

많은 API에서 링크는 주문 생성 시점에 고정됩니다. 동일한 ID로 새 링크를 전달하려는 시도는 무시되거나 오류로 처리되거나 예측할 수 없는 상태를 생성할 수 있습니다. 요청을 다시 보내면 주소가 자동으로 대체될 것이라고 기대하지 마세요.

문서에서 링크 편집을 직접 지원하는 경우 먼저 서비스가 아직 실행되지 않았는지 확인하세요. 그런 다음 이전 값, 새 값 및 API 응답을 저장하세요. 이는 클라이언트 또는 공급업체와의 분쟁 시 유용합니다.

편집의 단점은 방법이 사용 가능하더라도 업데이트 전에 일부 작업이 이전 페이지로 이동했을 수 있다는 것입니다. 수정된 링크는 이미 얻은 결과를 전송하지 않습니다.

부분 완료 시 해야 할 일

잘못된 링크로 프로모션이 이미 시작된 경우 남은 부분의 취소를 요청하세요. 공급업체에 대한 요청에 주문 ID, 잘못된 링크, 올바른 링크, 현재 상태 및 오류 발견 시간을 명시하세요. 요청 세부 정보를 여러 번 변경하지 마세요. 이는 기록 확인을 복잡하게 만듭니다.

남은 부분의 취소가 확인되면 이미 완료된 볼륨을 기록하세요. 공급업체 규칙에 명시된 경우 환불은 일반적으로 미실행 부분에만 적용됩니다. 완료된 볼륨은 기술적으로 한 채널, 동영상 또는 프로필에서 다른 곳으로 전송할 수 없습니다.

부분 취소의 단점은 분명합니다: 클라이언트가 이미 잘못된 페이지에서 결과를 받을 수 있으며 이 주문 부분의 예산이 항상 반환되지는 않습니다.

주문이 완료된 경우 별도의 요청으로 수정을 접수하세요

완료된 주문은 일반적으로 API를 통해 취소할 수 없습니다. 이러한 상황에서는 기록을 삭제하거나 기록의 링크를 변경하지 마세요. 원본 데이터는 대조를 위해 필요합니다. 서비스가 단순히 지연되어 표시되는 것이 아니라 실제로 잘못된 주소로 제공되었는지 확인하세요.

그런 다음 두 가지 경로가 있습니다: 공급업체 규칙에 따라 보상을 논의하거나 클라이언트와 합의한 후 올바른 링크로 새 주문을 생성하는 것입니다. 새 주문은 별도의 ID, 금액 및 생성 이유에 대한 명확한 메모를 가져야 합니다.

새 실행의 단점은 추가 예산이 필요하며 완료된 서비스에 대한 보상이 불가능할 수 있다는 것입니다.

재실행 전에 클라이언트에게 상황을 알리세요

링크가 클라이언트 소유이고 오류가 클라이언트 측에서 발생한 경우 임의로 대체를 실행하지 마세요. 원본 링크, 주문 상태, 취소 가능성 및 각 옵션의 결과를 클라이언트에게 보내세요. 서비스의 일부가 이미 완료된 경우 특히 중요합니다.

• 주문이 전달되지 않은 경우 올바른 링크를 요청하고 이전 요청의 취소를 확인하세요.
• 주문이 대기 중인 경우 취소가 전송되었지만 공급업체의 응답을 기다리고 있다고 알리세요.
• 부분 완료가 있는 경우 남은 부분만 중단할 수 있다고 명시하세요.
• 주문이 완료된 경우 새 실행 또는 다른 해결 방법을 합의하세요.

긴 합의의 단점은 그 시간 동안 대기 중인 주문이 처리로 넘어갈 수 있다는 것입니다. 따라서 가능한 경우 먼저 기술적 취소 요청을 보낸 다음 추가 조치를 명확히 하세요.

작업에 대한 로그 및 증거를 저장하세요

각 분쟁 주문에 대해 클라이언트의 원본 링크, 수신 날짜, 내부 번호, 공급업체 ID, API 요청 및 응답을 저장하세요. 클라이언트가 채팅에서 링크를 보낸 경우 원본을 저장하지 않고 주문 카드에서 편집된 버전으로 메시지를 대체하지 마세요.

누가 언제 오류를 발견했는지 별도로 기록하세요. 이는 잘못 전달된 데이터를 관리자 오류, 주문 양식 또는 자동 대체와 구분하는 데 도움이 됩니다. 공급업체에 반복적으로 문의할 때 모순이 발생하지 않도록 하나의 데이터 체인을 사용하세요.

수동 로그 유지의 단점은 시간이 걸린다는 것입니다. 그러나 기록 없이는 취소 상태를 확인하고 클라이언트에게 자금을 전액 환불할 수 없는 이유를 설명하기 어렵습니다.

통합에서 오류 처리를 확인하세요

이러한 사례 후에 시스템이 API로 링크를 전달하는 방법을 확인하세요. 오류는 클라이언트 때문만이 아닐 수 있습니다: 때때로 양식이 매개변수를 자르거나, 캐시에서 이전 값을 대체하거나, 게시물 링크 대신 프로필 링크를 수락하거나, 추가 문자가 있는 링크를 통과시킵니다.

주문 생성 전에 형식 확인을 추가하세요: 플랫폼, 서비스 유형 및 예상 객체와의 일치. 비디오 서비스의 경우 시스템은 동영상 링크와 채널 링크를 구분해야 하며 소셜 네트워크의 경우 프로필과 개별 게시물을 구분해야 합니다. 확인은 링크의 정확성을 보장하지 않지만 일부 명백한 오류를 걸러냅니다.

주문 전송은 짧은 데이터 확인으로 생성과 분리하는 것이 좋습니다. 추가 단계의 단점은 주문이 즉시 작업에 들어가지 않는다는 것이지만 잘못된 주소를 발견할 시간이 생깁니다.

팀을 위한 명확한 취소 시나리오를 설정하세요

통일된 절차를 설명하세요: 자동 전송 중단, 공급업체 상태 확인, 취소 전송, 응답 저장, 클라이언트에게 알림, 그런 다음에만 재실행 합의. 이러한 시나리오는 형식이 아니라 서로 다른 직원이 상호 배타적인 작업을 수행하지 않도록 하기 위해 필요합니다.

권한 제한 및 작업 로그 없이 취소에 대한 액세스를 제공하지 마세요. 여러 관리자가 동시에 하나의 주문으로 작업하는 경우 한 명은 취소를 요청하고 다른 한 명은 응답을 받기 전에 대체를 생성할 수 있습니다. 이는 추가 비용과 계산의 혼란을 초래합니다.

엄격한 시나리오의 단점은 긴급한 경우 유연성이 떨어진다는 것입니다. 그러나 API 주문의 경우 개별 작업의 속도보다 어떤 링크가 실제로 작업에 들어갔는지 제어하는 것이 더 중요합니다.