1

我们正在建立一个基于 Spree 并托管在 Heroku 上的在线商店。我们想让结帐尽可能简单，因此我们决定使用 PayPal Express Checkout 和 Instant Update API 来确定运费。

当我们通过 HTTP 测试结帐过程时，一切正常 - 当用户输入他的送货地址时，PayPal 在后台查询我们的服务器并获取运费。

但是，当我们切换到 SSL 时，运费不会更新并恢复为默认的统一费率。我不知道出了什么问题，因为一切都是一样的，除了这次应用程序是通过 HTTPS 访问的，即https://myapp.herokuapp.com

我检查了日志，发现 PayPal 的服务器确实进行了查询，但运费并未在 PayPal 的结帐页面上更新。

有什么想法吗？

更新：

经过进一步测试，PayPal 似乎没有遵守交易设置中设置的超时时间。我们在回调方法中添加了一个简单的“sleep(x)”来人为地诱导一些延迟（x 秒），即使在正常的 HTTP 上，仅仅 1 秒的延迟就足以导致 PayPal 忽略响应。

最大超时应该是 6 秒，但实际上似乎根本不是这种情况。再加上 HTTPS（建立连接需要更长的时间），这可能就是回调失败的原因。

我已经向 PayPal 提交了一张票，但我不确定他们是否会对此做出回应或采取任何措施......

4

2 回答 2

0

看来 PayPal 可能会忽略回调中返回的运输选项的原因有很多。

我想在 PayPal 的网站上看到一些东西，它会保留最近调用回调的历史记录以及返回的响应和拒绝的原因——有点类似于有用的 IPN 历史记录。

于 2013-03-12T15:37:14.553 回答
0

我很高兴您在这里发布了您的真实域名，因为您几乎证实了我的怀疑。

我非常确信问题在于您有一个通配符 SSL（我看到您的证书颁发给*.herokuapp.com），而不仅仅是单个域的 SSL。

我在使用www.MicroPedi.com5 名 UCC 证书的 UCC 证书时遇到了同样的问题。PayPal 完全拒绝甚至对它进行任何调用（我有日志记录，除了使用沙盒时什么都没有通过）。

为了确认这一点，我之前有一个运行良好的 Express 结帐实现（使用单个 SSL），我将我的新应用程序指向那个旧 URL，它神奇地再次开始工作。那是一个单一的名称 SSL - 实际上它是那些昂贵的green bar证书之一。

我已经直接写信给 PayPal 支持，但现在我唯一能想到的解决方法是编写某种代理页面，它只会从好的域重定向到我的 UCC 域。

于 2013-03-27T10:29:25.093 回答