Skip to main content
author: rossdyson author: akumaigorodski discussion: https://t.me/lnurl/256

​
Standardization of the successAction field

This defines a field successAction returned by the SERVICE along with the payment request in the second callback. It must be stored by the WALLET and shown to the user as soon as a payment succeeds. To implement this, a SERVICE must alter its JSON response to the second callback to include it like the following: 
 {
     "pr": string,
     "routes": [],
+   "successAction": Object
 }
In which Object has the format: 
{
   tag: string, // action type
   ...rest of fields depends on tag value
}
This document defines the message and the url types. See examples: 
{
  "tag": "message",
  "message": "Thank you for using bike-over-ln co! Your rental bike is unlocked now" // Up to 144 characters
}

{
   "tag": "url",
   "description": "Thank you for your purchase. Here is your order details", // Up to 144 characters
   "url": "https://www.ln-service.com/order/<orderId>" // url domain must be the same as `callback` domain at step 3
}

​
LNURL-pay flow change

A WALLET that decides to implement this scheme must, after a payment is complete and a successAction is present, show a popup or screen to the user with the contents of that successAction. For message, a toaster or popup is sufficient. For url, the wallet should give the user a popup which displays description, url, and a ‘open’ button to open the url in a new browser tab. WALLET should also store successAction data on the transaction record.

​
Support for successAction types

Since other successAction types can be added in the future, if a successAction is present in the response from SERVICE, a WALLET must make sure that its tag value is of a kind it supports, otherwise it must not proceed with the payment — or the user might end up paying and not seeing its expected successAction.