避免在超时情况下重复预订

在下列情况下,预订尝试可能会超时:

  • 联盟伙伴服务器超时设置太低
  • 供应商级别的预订处理系统速度较慢
  • 付款处理级别的付款网关速度较慢
  • 服务器因意外流量激增而超负荷

什么情况下会出现超时?

  • 如果联盟伙伴服务器的响应时间超过服务器设置,则会出现超时。我们建议至少设置 30 秒钟的时间,以便处理所有预订和付款。尽管基本上不会出现如此长的处理时间,但这要取决于供应商和付款网关的效率。
  • 如果供应商或付款网关在我们收到结果之前的运行时间超过我们的 60 秒超时设置,则我们自己的服务器上会出现超时。但是,处理仍可能会成功,即使所有系统在获知预订结果前均超时也是如此。遗憾的是,这意味着如不检查系统,我们可能不会收到所有确认信息。

如何确定在超时情况下仍会产生预订,或者是否会因任何级别的超时系统而返回空白预订结果?

请参见预订请求概述了解有关使用 affliateConfirmationId 的详细信息。affliateConfirmationId 可用于在发生不知道确认或行程是否成功的超时情况下查找预订。

  • 您可以通过在预订页面中包含用于处理超时预订或空白预订结果的特殊逻辑,从而避免重复预订。
  • 然后,将相关信息告知用户,并使用恰当的逻辑恢复预订。

affiliateConfirmationId (string)

  • 联盟伙伴唯一 ID 仅用于您自己的联盟伙伴跟踪或联盟伙伴个人用途
  • 必须是唯一值
  • 如果将相同的值发送两次(包括来自失败预订的值),预订将失败
  • 如果用户多次点击预订按钮,此值也可以用于避免重复预订。
  • 如果传入预订,我们将验证系统中不存在通过相同 affiliateConfirmationId 进行的预订。此外,联盟伙伴可以使用该 ID 从系统中检索行程。
  • 任何使用该字段的联盟伙伴均应确保该 ID 应真正唯一,如 GUID ID。
  • 该 ID 应在用户提交最终预订表之前创建。如果同一用户再次点击“提交”按钮,则会发送相同的 affiliateConfirmationId,并被系统检测为重复预订。
  • {: .red} 发送此元素时务必谨慎,因为在很多情况下,需要使用新的 affiliateConfirmationId 创建全新请求,例如预订失败或预订不可恢复。
  • 此项旨在用于
  • 您的个人跟踪
  • 避免用户提交重复预订/费用
  • 在因第三方系统上的超时过程导致预订超时或返回空白结果时,检查系统以获得行程

确定预订请求出现超时或返回空白结果时是否存在预订的步骤。

  1. 使用唯一 affiliateConfirmationId 发送预订请求
  2. 经过很长一段时间后出现超时或未返回结果
  3. 在超时或返回空白预订结果后,使用唯一的 affiliateConfirmationId 提出行程请求。

  4. 此行程请求将返回针对该 affiliateConfirmationId 的任何行程信息(如果创建了行程)。

  5. 请求同时还会显示该行程的状态。
  6. CF - 已确认预订
  7. PS - 待定\:通常如果返回 handling=3 则返回此信息,且此时代理必须完成预订。EAN 将继续尝试处理这些预订,并可能会将状态处理为 CF 或 UC,而不另行通知。
  8. UC - 未确认\:此预订将不再可用,且不会确认。
  9. DT - 已删除\:请求已被取消,且行程已从任何统计信息中删除。通常,发生不可恢复错误的预订请求会出现该情况。 ^

  10. 如果非 CF 状态的行程请求返回结果

  11. 提醒用户预订出现问题,并提供预订状态。
  12. 如果返回 handling = 3,代理将在 24 小时内与用户联系。
  13. 您也可以为客户提供选项来取消预订请求,并创建新的预订请求。
  14. 如果取消请求,请使用获取的行程信息提交针对该预订尝试的取消请求。
  15. 这会告知代理不需要跟进该预订尝试。

  16. 如果行程请求返回带 CF 状态的结果

  17. 向用户展示行程结果中的成功预订结果,与预订未出现任何超时即成功确认一样。

  18. 如果未返回结果

  19. 预订请求超时期间未生成预订。
  20. 提醒用户处理预订时出现问题,并为他们提供酒店的跟进选项,以便用户再试一次。
  21. 请务必发出新的 affiliateConfirmationId,因为该值在每个预订请求中必须唯一。

避免重复提交

每次点击无限制的“提交”按钮或刷新同一预订的预订页面时,用户都会创建重复预订。

由于 Web、电子系统和其他不可控因素的性质,传输的提交内容和响应时间有时候会出现延迟。

  • 如果出现延迟,用户可能会失去耐心,并多次点击预订提交按钮。
  • 在这些情况下,系统会为发送的每个提交创建一个新预订。
  • 由于实际确认回复会被较新的回复覆盖,用户可能会在收件箱中发现多封确认邮件或到达酒店之后,才发现或意识到已多次提交预订,而且实际上已在您的网站上重复进行了预订。

重复预订对用户有何影响?

  • 在预付费预订中,这意味着每次收到重复提交并创建新的预订记录后,系统都会从用户信用卡中扣除费用。
  • 在 Hotel Collect/Hotel Collect 预订中,这会在该系统中为同一用户创建多个针对同一家酒店的预订。
  • 酒店会将此视为多个客房预订,并要求旅客在入住时为每间客房支付费用,因为每间客房都已由旅客的信用卡担保,并未订给其他客户。

重复预订对联盟伙伴有何影响?

  • 每个联盟伙伴均负责创建自己的应用程序,因此,联盟伙伴也需对他们的客户负责。
  • 如果未能妥善处理客户纠纷,则会产生不必要的收费,而该费用将由联盟伙伴直接承担。

为避免重复预订,请在预订页面上添加处理多个提交的特殊逻辑,并将相关信息发送给用户。

  • 在很多情况下,只需声明多次点击会向他们的信用卡重复收费,即可避免大多数这类问题。
  • 您也可以添加简单代码,以在第一次点击事件后禁用预订页面的“提交”按钮,避免在加载过程中重复点击该按钮。
  • 在其他 Web 故障情况下,您需要进行特殊处理,确保在只需要进行一次预订时不会将预订发送两次。

采取特殊处理时也需要注意,通过重新提交请求可解决某些预订错误。

  • 您可以根据失败的性质和预订时所返回异常的处理代码,确定是否需要重新提交预订。
  • 在这些情况下,预订不会重复,而是再次重试提交,以保证处理成功。

请参见预订请求概述,了解有关使用 <affliateConfirmationId> 的详细信息。该参数可帮助我们的系统检测重复的预订尝试。

最后,利用行程请求检查现有的行程或现有行程的状态。