Apps/WebApplicationReceipt: Difference between revisions

Apps/WebApplicationReceipt (view source)

22 bytes added , 3 November 2011

no edit summary

348

edits

@@ Line 89: / Line 89: @@
 === Interaction with the <tt>verify</tt> URL ===
-If the <tt>verify</tt> URL is present, the receiving party may verify it by issuing a GET request to it.  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".
-This verification is not required, but is provided to support real-time queries.  Receipt issuers SHOULD require application authentication on this call, to prevent enumeration attack.  Receipt issuers are encouraged to use a sparse, non-guessible receipt sequence ID if they do not authenticate verification calls.  (TODO: If it's just a status field, does enumeration really matter?  Perhaps none of this language is required.)
+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.
+Applications are free to re-query the verifyURL field as often as they see fit; whether this is a one-time or an every-time interaction, or something in between, is up to the application implementor to decide.
 == References ==