Confirmed users
1,158
edits
Apps/WebApplicationReceipt: Difference between revisions
→Interaction with the verify URL
| Line 121: | Line 121: | ||
If the <tt>verify</tt> URL is present, the receiving party may verify it by issuing a POST request to it, where the message body contains the complete receipt. The return value of this request is a JSON object with fields: | If the <tt>verify</tt> URL is present, the receiving party may verify it by issuing a POST request to it, where the message body contains the complete receipt. The return value of this request is a JSON object with fields: | ||
* <tt>status</tt>: A string, containing one of the values "ok", "pending", "refunded", or "invalid". | * <tt>status</tt>: A string, containing one of the values "ok", "pending", "refunded", "expired" or "invalid". | ||
Application-level authentication on the verifyURL request is not strictly required, as the possession of a receipt proves that the application is already part of a trusted message flow. | Application-level authentication on the verifyURL request is not strictly required, as the possession of a receipt proves that the application is already part of a trusted message flow. | ||