Re: [w3c/browser-payment-api] The myth of JSON-serializable object (#307)

I think I see. Hmm, so if it's in another process, we can't do synchronous validation of the data, right? So we can't throw an exception in the constructor. In that case the flow should be something more like:

- In the constructor, do JSON.stringify. Store the resulting string.
- When we invoke the "user accepts the payment request algorithm", send the string to the payment method (e.g. to basic card).
- Basic card first does JSON.parse on the resulting string. This will never fail since it was produced by JSON.stringify.
- Then basic card converts the resulting parsed JS object to a dictionary. This can fail. At this point there would need to be a communication channel for showing an error back to the user.

Does this sound right?

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/browser-payment-api/issues/307#issuecomment-267146564