在为我的iOS应用创建应用购买策略时,我遇到了一些困惑。下面有一些背景信息;
我有一个iOS应用程序和一个Web应用程序,它们都可以在订阅模型中使用。后端是在Ruby on Rails中开发的。
目前我正在尝试在应用购买中开发iOS自动续订。我遇到了几个宝石,有助于验证应用购买收据(例如Venice)。我知道从后端验证收据的重点,而不是客户端是为了使其安全,并能够在自己的服务器中保留收据的副本。
我可以预见到一个巨大的问题,如下所述;
用户可以使用iOS应用创建帐户,并使用x@x.com apple id每月支付X美元订阅该服务。通过这样做,我将在我的后端记录该用户的记录,包括他的订阅的到期日期,这将使我能够跟踪他是否续订了他的订阅。当此用户从应用程序注销并创建另一个用户时,会出现问题。由于他的苹果ID仍然是x@x.com,并且当从苹果购买时帐户电子邮件地址或ID无关紧要,因为他刚刚订阅了他之前的帐户,因此到期日仍然是一个月用户将被识别为已付费客户。繁荣!现在,他的朋友可以使用网络应用程序使用此帐户登录并享受它而无需付费。
如果这对你有意义,那么必须有一个解决方案。我知道Netflix使用Apple的IAP,Spotify使用了很长时间。
还有像威尼斯这样的宝石,他们没有在他们的github页面上放置完整的文档,因此我不知道这个问题是否可以通过它们解决。只是想和你们一起检查,我相信很多人都会想到这个。
答案 0 :(得分:0)
如果您将自动续订购买归因于数据库中的用户,您还需要归因收据中的original_transaction_id
。使用expires_date
存储此ID,并忽略或错误包含已接收到的已归因于数据库中其他用户的API original_transaction_id
的所有收据。
对于iTunes用户,original_transaction_id
永远不会改变,即使他们取消订阅并在以后重新订阅它将保持不变。如果产品ID属于同一订阅系列,则升级/降级订阅的持续时间也将保持不变。
如果您正在寻找威尼斯的替代品,请查看itunes_receipt_validator宝石(完全披露:我是作者)。它在本地验证已弃用的交易收据和较新的大型统一收据的签名和解码,而无需连接到Apple的API,但也提供了检索更新的收据和来自Apple API的收据信息。