1. ngRoute无法处理通过POST访问的URL，如果您已经在index.html上进行了重写，而只是发布到index.html而不是您的路由，则在配置/ booking-success并通过cURL对该URL进行POST时将无法正常工作您实际上是发布到index.html。角形布线只是“虚拟”的，不是真实的。诸如cURL或任何其他HTTP客户端之类的系统看不到它，因此它们正在发布到index.html。

2. 切勿在angular内处理来自付款/预订/任何网关的回调URL。Angular是危险的，因为您必须确保将执行回调过程。Angular不是容错的，如果有任何javascript错误，Angular调用内的任何错误都将丢失所有回调数据，并且字面上就是搞砸了。

回调必须是REST
API的一部分，并且必须实现以返回HTTP状态代码200，否则，如果使用任何其他HTTP代码，网关应知道它们必须重试调用。（例如，如果没有HTTP
200代码，skrill.com将重复执行10次回调）。实际上，AngularJS每次都会以200响应，因为您的Web服务器将提供index.html，它并不关心javascript代码内部会发生什么。

1. 只能通过angular处理的部分是redirect_url，通常是用户在经纪人端成功付款/操作后重定向到的URL。但是与此同时，回调URL仍在应用程序的较低级别上调用。重定向URL在浏览器重定向中通过GET调用，因此用户会正常看到它。

每个“正常”网关都有callback_url（向API发出低级通知，表明该操作已成功完成redirect_url，并且重定向到您的网站xyz.com/booking-
success）。但是它们应该分开。如果您的网关没有重定向，则别无选择，只能在新窗口中打开整个预订。并在调用回调后以某种方式通知您的前端。可以通过间隔轮询来完成。例如，10秒正在检索您的实际状态booking_id（is_processed (true|false)您将在回调代码中设置的列。状态从false更改为true时，您将通知您的前端（重定向用户或显示弹出窗口）。您还可以实现套接字。
io库，您可以处理轮询，并且在调用回调URL时，您的通知将立即生效。