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
A client can support one-time payments by obtaining the necessary grants and calling the Open Payments APIs to create the incoming payment, quote, and outgoing payment resources.
14
+
Add support for one-time payments to your client. A one-time payment is a single, non-recurring payment.
13
15
:::
14
16
15
17
The Open Payments APIs facilitate multiple use cases for one-time payments to and from Open Payments-enabled wallets. Making a payment directly from one person to another, called a peer-to-peer payment, is one example. Purchasing an item from an online merchant and paying in full is another example.
@@ -143,42 +145,17 @@ Now indicate your client can receive a signal from the authorization server when
143
145
144
146
### 7. Start interaction with the user
145
147
146
-
Once your client receives the authorization server’s response, it must send the user to the `interact.redirect` URI contained in the response. This starts the interaction flow.
147
-
148
-
The response also includes a `continue` object, which is essential for managing the interaction and obtaining explicit user consent for outgoing payment grants. The `continue` object contains an access token and a URI that the client will use to finalize the grant request after the user has completed their interaction with the identity provider (IdP). This ensures that the client can securely obtain the necessary permissions to proceed with the payment process.
The user interacts with the authorization server through the server’s interface and approves or denies the grant.
171
-
172
-
Provided the user approves the grant, the authorization server:
173
-
174
-
- Sends the user to your client’s previously defined `finish.uri`. The means by which the server sends the user to the URI is out of scope, but common options include redirecting the user from a web page and launching the system browser with the target URI.
175
-
- Secures the redirect by adding a unique hash, allowing your client to validate the `finish` call, and an interaction reference as query parameters to the URI.
152
+
<FinishInteraction />
176
153
177
154
### 9. Request a grant continuation
178
155
179
-
After the user completes their interaction with the identity provider (IdP), they should be redirected back to your application. At this point, you can make the grant continuation request. In scenarios where a user interface is not available, consider implementing a polling mechanism to check for the completion of the interaction.
156
+
After the user completes their interaction with the identity provider (IdP), they should be redirected back to your application. Now you can make the grant continuation request. In scenarios where a user interface is not available, consider implementing a polling mechanism to check for the completion of the interaction.
180
157
181
-
Add the authorization server’s interaction reference, as the `interact_ref` value, to the body of your continuation request.
158
+
Add the authorization server’s interaction reference as the `interact_ref` value to the body of your continuation request.
@@ -191,8 +168,7 @@ Issue the request to the `continue uri` supplied in the authorization server’s
191
168
192
169
A successful continuation response from the authorization server provides your client with an access token and other information necessary to continue the transaction.
A client can support recurring payments by obtaining the necessary grants and calling the Open Payments APIs to create the incoming payment, quote, and multiple outgoing payment resources.
14
+
Add support for recurring payments to your client. A recurring payment requires the sender's authorization once, then automatically pays out at regular intervals.
13
15
:::
14
16
15
17
The Open Payments APIs facilitate multiple use cases for recurring payments to and from Open Payments-enabled wallets. Buy Now Pay Later (BNPL) is one example, where a purchaser pays for an item in installments over regularly scheduled intervals.
@@ -150,42 +152,17 @@ Now indicate your client can receive a signal from the authorization server when
150
152
151
153
### 7. Start interaction with the user
152
154
153
-
Once your client receives the authorization server’s response, it must send the user to the `interact.redirect` URI contained in the response. This starts the interaction flow.
154
-
155
-
The response also includes a `continue` object, which is essential for managing the interaction and obtaining explicit user consent for outgoing payment grants. The `continue` object contains an access token and a URI that the client will use to finalize the grant request after the user has completed their interaction with the identity provider (IdP). This ensures that the client can securely obtain the necessary permissions to proceed with the payment process.
The user interacts with the authorization server through the server’s interface and approves or denies the grant.
178
-
179
-
Provided the user approves the grant, the authorization server:
180
-
181
-
- Sends the user to your client’s previously defined `finish.uri`. The means by which the server sends the user to the URI is out of scope, but common options include redirecting the user from a web page and launching the system browser with the target URI.
182
-
- Secures the redirect by adding a unique hash, allowing your client to validate the `finish` call, and an interaction reference as query parameters to the URI.
159
+
<FinishInteraction />
183
160
184
161
### 9. Request a grant continuation
185
162
186
-
After the user completes their interaction with the identity provider (IdP), they should be redirected back to your application. At this point, you can make the grant continuation request. In scenarios where a user interface is not available, consider implementing a polling mechanism to check for the completion of the interaction.
163
+
After the user completes their interaction with the identity provider (IdP), they should be redirected back to your application. Now you can make the grant continuation request. In scenarios where a user interface is not available, consider implementing a polling mechanism to check for the completion of the interaction.
187
164
188
-
Add the authorization server’s interaction reference, as the `interact_ref` value, to the body of your continuation request.
165
+
Add the authorization server’s interaction reference as the `interact_ref` value to the body of your continuation request.
@@ -198,8 +175,7 @@ Issue the request to the `continue uri` supplied in the authorization server’s
198
175
199
176
A successful continuation response from the authorization server provides your client with an access token and other information necessary to continue the transaction.
0 commit comments