davidiw
commented
3 years ago I think this type of work is really exciting and would love to dig into it!
With that being said, I want to begin torturing Kevin:
- Need more contents in abstract than “This is inclusive of pull payments, recurring payments, and auth/capture flows.”
- goal / problem statement for fund pre-approval isn’t very clear, needs a better strawman example or just being broken down specifically what each protocol is trying to attempt (I like bullet points) -- for example, what is the properly end-to-end flow involving outside -- should I as a consumer pre-authorize something, will this appear in my account to confirm, it feels like something is missing here.
- Why does Auth/Capture leverage PaymentCommand versus another command? We would likely still need to perform a KYC prior to TR transactions anyway and we can leverage the slightly new style of performing these types of request / responses (no need for an explicit callback can handle in a single http request / response)
- If we use new commands, then the “version” of the API is irrelevant and instead it is whether or not certain commands are supported -- in fact -- we should really figure out a versioning for objects (maybe just different names) than versioning the API because the API should only change if we adjust the CommandObject format or change the format of the lower level protoocols.
- The usage of headers is inconsistent # defines specifications and several fields within specifications (e.g., Auth/Capture), children then use ###, we’re skipping ##, the madness
kphfb
Updating LIP 8 to match the changes to LIP-1 as per version 2 of LIP-1 which simplified the flow of LIP-1