Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow creating remote incoming payments via GraphQL API #938

Closed
sabineschaller opened this issue Jan 9, 2023 · 2 comments · Fixed by #986
Closed

Allow creating remote incoming payments via GraphQL API #938

sabineschaller opened this issue Jan 9, 2023 · 2 comments · Fixed by #986
Assignees
Milestone

Comments

@sabineschaller
Copy link
Member

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.

@sabineschaller sabineschaller added this to the Rafiki v1 milestone Jan 9, 2023
@mkurapov mkurapov self-assigned this Jan 9, 2023
@mkurapov
Copy link
Contributor

@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:

input CreateIncomingPaymentInput {
  paymentPointerId: String!
  expiresAt: String
  description: String
  incomingAmount: AmountInput
  externalRef: String
}

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?

@wilsonianb
Copy link
Contributor

+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?

✔️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
Status: Done
Development

Successfully merging a pull request may close this issue.

3 participants