시간 초과 시 중복 예약 방지

다음과 같은 경우 예약 시도 시간이 초과될 수 있습니다.

  • 제휴사의 서버 시간 초과 설정 값이 너무 낮을 경우
  • 예약 프로세스 시스템이 공급업체 단계에서 너무 느릴 경우
  • 결제 프로세스 단계에서 결제 게이트웨이가 너무 느릴 경우
  • 예기치 않은 트래픽 증가로 서버가 오버로드되는 경우

시간 초과 발생 위치

  • 서버 설정보다 응답이 오래 걸릴 경우 제휴사 서버에서 시간 초과가 발생할 수 있습니다. 모든 예약 및 결제 프로세스에는 최소 30초가 적당합니다. 간혹 당사에서 처리 시간이 오래 걸리기도 하지만 공급업체 및 결제 게이트웨이에서 주로 발생합니다.
  • 공급업체나 결제 게이트웨이가 당사에서 결과를 수신하도록 설정한 60초보다 오래 실행되는 경우 서버에 시간 초과가 발생할 수 있습니다. 예약 결과가 제시되기 전에 모든 시스템의 시간이 초과하더라도 프로세스가 성공할 수도 있습니다. 하지만 이런 경우 당사에서 시스템을 확인하지 않으면 모든 확인 정보를 알 수 없습니다.

예약 시 시간 초과가 발생했는지 또는 시스템의 특정 단계에서 시간 초과가 발생하여 예약 결과가 공백으로 반환되었는지 확인하는 방법

affliateConfirmationId 사용에 대한 자세한 내용은 예약 요청 요약을 참조하세요. 시간 초과가 발생하여 확인 또는 일정을 알 수 없는 예약을 검색할 때 사용할 수 있습니다.

  • 예약 페이지에 시간 초과된 예약이나 비어 있는 예약 결과를 처리할 수 있도록 특수한 로직을 포함시키면 예약 중복을 방지할 수 있습니다.
  • 이렇게 하면 사용자에게 적절한 정보가 메시지로 전달되며 해당 로직을 사용하여 예약을 복구할 수 있습니다.

affiliateConfirmationId(제휴사 확인 ID) (문자열)

  • 제휴사 고유 ID는 자체 제휴사 추적 또는 제휴자의 개인적인 목적으로 사용됩니다.
  • 고유한 값이어야 합니다.
  • 동일한 값이 두 번 전송되면(실패한 예약 값 포함) 예약에 실패합니다.
  • 사용자가 예약 버튼을 두 번 이상 클릭하는 경우 중복 예약을 방지하는 데 이 값을 사용할 수 있습니다.
  • 전달된 경우 같은 affiliateConfirmationId(제휴사 확인 ID)로 이미 시스템에 만든 예약이 없는지 확인합니다. 또한 제휴사가 같은 ID를 사용하여 시스템에서 일정을 검색할 수도 있습니다.
  • 이 필드를 사용하는 모든 제휴사는 ID가 GUID ID 같이 실제로 고유한지 확인해야 합니다.
  • ID는 사용자가 최종 예약 양식을 제출하기 전에 만들어야 합니다. 같은 사용자가 제출 버튼을 다시 누르면 동일한 affiliateConfirmationId(제휴사 확인 ID)가 전송되고 중복 예약으로 감지됩니다.
  • 실패한 예약 또는 복구할 수 없는 오류와 같이 새로운 affiliateConfirmationId(제휴사 확인 ID)를 사용하여 요청을 새로 해야 하는 경우가 많기 때문에 이 요소를 전송할 때는 특히 주의하세요.
  • 이 항목은 다음 목적으로 사용됩니다.
    • 자체 추적
    • 사용자의 중복 예약/청구 제출 방지
    • 타사 시스템에서 시간 초과가 발생하여 예약 시간이 초과하거나 빈 결과가 반환된 경우 시스템에서 일정을 확인하세요.

다음은 예약 요청에서 시간 초과가 발생하거나 빈 결과가 반환되었을 경우 확인하는 단계입니다.

  1. 고유 affiliateConfirmationId(제휴사 확인 ID)로 예약 요청을 전송합니다.
  2. 시간이 오래 걸려 시간 초과가 발생하거나 결과가 반환되지 않습니다.
  3. 시간 초과 또는 빈 예약 결과 세트에 affiliateConfirmationId(제휴사 확인 ID)를 사용하여 일정 요청을 합니다.

  4. 이러한 일정 요청을 하면 해당 affiliateConfirmationId(제휴사 확인 ID)에 대한 모든 일정 정보(일정 정보가 생성된 경우)를 반환합니다.

  5. 또한 해당 일정에 대한 상태를 표시합니다.

    • CF - 확인된 예약
    • PS - 보류 중\: 이것은 상담원이 예약을 완료해야 하는 handling=3이 반환된 경우 항상 반환됩니다. EAN은 이러한 예약을 처리하기 위해 지속적으로 시도하여 추가 공지 없이 CF 또는 UC를 해결할 수 있습니다.
    • UC - 확인되지 않음\: 이 예약은 사용할 수 없으며 확인되지 않습니다.
    • DT - 삭제됨\: 요청이 취소되며 해당 일정이 모든 통계에서 삭제됩니다. 이것은 일반적으로 복구할 수 없는 오류가 발견된 예약 요청에서 발생합니다. ^
  6. 일정 요청에서 CF 이외의 다른 상태 결과가 반환된 경우

    • 사용자에게 예약에 문제가 있음을 알리고 예약 상태를 제공합니다.
    • handling = 3이 반환된 경우 상담원이 24시간 이내에 사용자에게 연락합니다.
    • 또한 고객에게 예약 요청을 취소하고 새 예약을 시작할 수 있는 옵션을 제공할 수 있습니다.
    • 요청을 취소하는 경우 확보한 일정 정보를 사용하여 해당 예약 시도에 대한 취소 요청을 제출할 수 있습니다.
    • 이렇게 하면 상담원에게 해당 예약에 대한 후속 조치가 필요하지 않음을 알리게 됩니다.
  7. {: .red} 일정 요청에서 CF 결과가 반환된 경우

    • 일정에서 성공적인 예약 결과를 표시하면 시간 초과 없이 예약이 성공적으로 확인된 경우와 동일한 결과가 사용자에게 제공됩니다.
  8. 결과가 반환되지 않는 경우

    • 시간 초과된 예약 요청 중에는 예약 결과가 없습니다.
    • 사용자에게 예약 처리 중에 문제가 발생했음을 알리고 다시 시도할 수 있는 선택권을 후속 조치로 제공합니다.
    • affiliateConfirmationId(제휴사 확인 ID)는 모든 예약 요청에서 고유 값이어야 하기 때문에 새 affiliateConfirmationId를 발행합니다.

중복 제출 방지

사용자가 제출 버튼을 무제한으로 클릭하거나 동일한 예약에 대해 예약 페이지를 새로 고침할 때마다 중복된 예약이 생성됩니다.

웹의 특성, 전자 시스템 또는 그 외 제한되지 않는 요소로 인해 전송된 제출 및 응답 시간이 지연될 수 있습니다.

  • 이러한 문제가 발생하면 사용자가 예약 제출 도구를 여러 번 클릭할 수 있습니다.
  • 이 경우 제출할 때마다 새로운 예약이 생성됩니다.
  • 새 응답이 실제 확인 응답을 덮어쓸 수 있기 때문에 사용자는 받은편지함에서 확인 전자 메일을 발견하거나 시설에 표시될 때까지 예약이 한 번 이상 제출되어 사이트에서 실제로 중복되었음을 알거나 감지할 수 없습니다.

중복 예약이 사용자에게 미치는 영향

  • 선불 예약인 경우 중복된 제출이 수신되고 새 예약 기록이 생성될 때마다 신용카드에 청구됨을 의미합니다.
  • Hotel Collect/Hotel Collect 예약의 경우 해당 시스템에서 동일한 숙박업소에 대해 같은 사용자에게 중복된 예약을 생성합니다.
    • 숙박업소에서는 이를 여러 개의 객실을 예약한 것으로 봅니다. 각 객실에는 신용카드 보증이 설정되어 다른 고객에게 판매되지 않기 때문에 투숙객이 체크인 시 모든 객실에 대해 비용을 지불할 책임을 지게 됩니다.

중복 예약이 제휴사에 미치는 영향

  • 모든 제휴사는 자체 응용 프로그램을 개발할 책임이 있으며 고객에 대해서도 책임을 져야 합니다.
  • 적절한 처리가 실행되지 않을 경우 고객 분쟁으로 인해 제휴사에 직접 청구되는 불필요한 금액이 발생할 수 있습니다.

중복된 예약을 방지하기 위해 특수 로직을 예약 페이지에 삽입하여 중복된 제출을 처리하고 사용자에게 적절한 정보를 제공해야 합니다.

  • 대부분의 경우 한 번 이상 클릭하면 신용카드가 중복 청구된다고 간단히 설명하여 심각한 문제가 발생하는 것을 방지합니다.
  • 또한 첫 번째 클릭 이후 예약 페이지의 제출 버튼을 비활성화하도록 단순 코드를 추가하여 로드 중 반복된 클릭을 방지할 수 있습니다.
  • 그 외 웹 실패 케이스의 경우 한 개의 예약을 의도했을 때 예약이 두 번 전송되지 않도록 특별히 처리해야 합니다.

특별 처리의 경우 일부 예약 오류는 요청을 다시 제출하여 해결할 수 있음을 기억해야 합니다.

  • 예약 시간에 반환되는 실패 및 처리 예외 속성에 따라 예약을 다시 제출해야 할지 결정할 수 있습니다.
  • 이러한 경우 예약이 중복되지만 성공적인 처리를 위해 다시 시도됩니다.

<affliateConfirmationId> 사용에 대한 자세한 내용은 예약 요청 요약을 참조하세요. 시스템에서 중복된 예약 시도를 감지하는 데 도움이 될 수 있습니다.

마지막으로 일정 요청을 사용하여 기존 일정이나 기존 일정 상태를 확인할 수 있습니다.