Changes

If the <tt>verify</tt> URL is present, the receiving party may verify it by issuing a GET POST request to it, where the message body contains the complete receipt. The return value of this request is a JSON object with fields:

This verification Application-level authentication on the verifyURL request is not strictly required, but as the possession of a receipt proves that the application is provided to support real-time queries. Receipt issuers SHOULD require application authentication on this call, to prevent enumeration attackalready part of a trusted message flow. Receipt issuers  Applications are encouraged free to use a sparse, nonre-guessible receipt sequence ID if query the verifyURL field as often as they do not authenticate verification calls. (TODO: If it's just see fit; whether this is a status fieldone-time or an every-time interaction, or something in between, does enumeration really matter? Perhaps none of this language is requiredup to the application implementor to decide.)