You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Alice is a customer at Wallet1 and Bob is a customer at Wallet2. Alice wants to send a P2P payment to Bob on Wallet1's UI.
The UI uses the GraphQL API to create payments and quotes. However, using the GraphQL API, the UI can only create incoming payments at Wallet1, not at Wallet2. Hence, we need to allow creating incoming payments on Wallet2 using the GraphQL API. Ideally, this uses the same CreateIncomingPayment endpoint we already have and under the hood it figures out whether the API call wants to create a local or a remote incoming payment.
The text was updated successfully, but these errors were encountered:
@sabineschaller@wilsonianb
In order to keep the same endpoint, we would have to update the CreateIncomingPaymentInput or make a new mutation. An admin wouldn't know the paymentPointerId (e.g. uuid) of the customer at Wallet 2:
Likewise, does it make sense returning the paymentPointerId in the IncomingPaymentResponse also?
Maybe we could just provide paymentPointerUrl instead, in both the input type and the response type?
I'm leaning toward making a separate mutation (ie. CreateRemoteIncomingPayment): if we keep the single CreateIncomingPayment mutation that is able to create both local and remote incoming payments, as a user of the API, I would expect CreateQuote or CreateOutgoingPayment maybe to also support remote and local quotes/payments.
In general, what could the Admin UI look like when making a P2P payment? Would we have a three step P2P process (on a separate page, for example) that 1) creates the remote incoming payment, 2) creates the local quote (and displaying it to the admin), then 3) creates/confirms the outgoing payment?
+1 for CreateRemoteIncomingPayment
unless we wanted to do a hard shift throughout the admin api from paymentPointerId to paymentPointerUrl(?)
In general, what could the Admin UI look like when making a P2P payment? Would we have a three step P2P process (on a separate page, for example) that 1) creates the remote incoming payment, 2) creates the local quote (and displaying it to the admin), then 3) creates/confirms the outgoing payment?
Alice is a customer at Wallet1 and Bob is a customer at Wallet2. Alice wants to send a P2P payment to Bob on Wallet1's UI.
The UI uses the GraphQL API to create payments and quotes. However, using the GraphQL API, the UI can only create incoming payments at Wallet1, not at Wallet2. Hence, we need to allow creating incoming payments on Wallet2 using the GraphQL API. Ideally, this uses the same
CreateIncomingPayment
endpoint we already have and under the hood it figures out whether the API call wants to create a local or a remote incoming payment.The text was updated successfully, but these errors were encountered: