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
Copy file name to clipboardExpand all lines: SPEC1.1.md
+24-2Lines changed: 24 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,7 +12,7 @@ A standard URL protocol for requesting native SOL transfers, SPL Token transfers
12
12
13
13
These URLs may be encoded in QR codes or NFC tags, or sent between users and applications to request payment and compose transactions.
14
14
15
-
Applications should ensure that a transaction has been confirmed and is valid before they release goods or services being sold, or grant access to objects or events.
15
+
Applications should ensure that a transaction has been confirmed and is valid before they release goods or services being sold, or grant access to objects or events.
16
16
17
17
Mobile wallets should register to handle the URL scheme to provide a seamless yet secure experience when Solana Pay URLs are encountered in the environment.
18
18
@@ -29,6 +29,7 @@ solana:<recipient>
29
29
&label=<label>
30
30
&message=<message>
31
31
&memo=<memo>
32
+
&success-redirect=<success-redirect>
32
33
```
33
34
34
35
The request is non-interactive because the parameters in the URL are used by a wallet to directly compose a transaction.
@@ -78,6 +79,12 @@ The wallet must [URL-decode](https://developer.mozilla.org/en-US/docs/Web/JavaSc
78
79
79
80
If the field is provided, the wallet must include a `MemoProgram` instruction as the second to last instruction of the transaction, immediately before the SOL or SPL Token transfer instruction, to avoid ambiguity with other instructions in the transaction.
80
81
82
+
### Success Redirect
83
+
84
+
A single `success-redirect` field is allowed as an optional query parameter. The value must be a conditionally [URL-encoded](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/encodeURIComponent) absolute HTTPS or solana URL.
85
+
86
+
The wallet must [URL-decode](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/decodeURIComponent) the value. If it is a HTTPS URL then the wallet should display the decoded value to the user. If the transaction is completed successfully and it is a HTTPS URL then the wallet should redirect the user to the URL. If the transaction is completed successfully and it is a solana URL then the wallet should treat it as a new Solana Pay request. If the transaction is not completed successfully then the wallet should not use the URL.
87
+
81
88
### Examples
82
89
83
90
##### URL describing a transfer request for 1 SOL.
A Solana Pay transaction request URL describes an interactive request for any Solana transaction.
@@ -187,10 +199,20 @@ The `<message>` value must be a UTF-8 string that describes the nature of the tr
187
199
188
200
For example, this might be the name of an item being purchased, a discount applied to the purchase, or a thank you note. The wallet should display the value to the user.
189
201
202
+
The application may also include an optional `successRedirect` field in the response body:
The `success-redirect` field must be a conditionally [URL-encoded](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/encodeURIComponent) absolute HTTPS or solana URL.
209
+
210
+
The wallet must [URL-decode](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/decodeURIComponent) the value. If it is a HTTPS URL then the wallet should display the decoded value to the user. If the transaction is completed successfully and it is a HTTPS URL then the wallet should redirect the user to the URL. If the transaction is completed successfully and it is a solana URL then the wallet should treat it as a new Solana Pay request. If the transaction is not completed successfully then the wallet should not use the URL.
211
+
190
212
The wallet and application should allow additional fields in the request body and response body, which may be added by future specification.
191
213
192
214
#### Error Handling
193
-
If the application responds with an HTTP [client](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status#client_error_responses) or [server](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status#server_error_responses) error in response to the POST or PUT operations, the wallet must consider the entire transaction request as failed.
215
+
If the application responds with an HTTP [client](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status#client_error_responses) or [server](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status#server_error_responses) error in response to the POST or PUT operations, the wallet must consider the entire transaction request as failed.
194
216
195
217
Client and server errors may optionally be accompanied by a JSON body containing a UTF-8 string `message` field describing the nature of the error:
0 commit comments