XUMM PYTHON SDK: 4. Verify the results ⛑ and push 🚀

#xrpl #xrp #xumm #sdk

You have now sent a payload to the XUMM platform using the XUMM SDK and have now received a XUMM sign request.

You opened the next.always URL, scanned the QR code with your smartphone running XUMM (or from your smartphone and got redirected to the XUMM app) and you have signed your first request. Well done!

Before we move on we must first verify the payload outcome. As we discussed before, once signed, you would receive a user token to send your next payload using a Push notification.

Please note: this is where this tutorial gets more technical. Software developers will be able to follow this. If you've never coded before this will probably require some further time to learn and understand what is happening and how to achieve the desired end result.

In this part of the transaction we are not just creating a sign request by sending a payload, we are also subscribing to payload events. We will use the following methods in our code. sdk.payload.create() and sdk.payload.create_and_subscribe().

The create_and_subscribe method accepts the payload in the first argument (just like the create method), but the second argument is a function that gets invoked every time the XUMM platform asynchronously sends an update about the created payload.

The subscription for payload events will stay alive until something is returned by the function (second argument) that is passed to the create_and_subscribe method. Here is an example:

When you execute this code, you will immediately see the payload response containing the URL to open the payload. At the end of the code we console log the subscription.created object, containing the created payload data that we previously got directly from the create() method.

The other code only executes immediately after this, as the first payload events are fired once the SDK connects to the XUMM platform.

If the event data contains a signed property, depending on whether the payload has been signed, causes the callback function to print a message, and return either the event data (if signed) or a boolean false (if rejected). By returning something (anything), the subscription then ends.

Let's test this example. Open the created payload URL on your desktop, and while the SDK is waiting for status updates, try scanning the QR code with XUMM. You should now see the opened event live in your terminal 😎

When this is working successfully, we will then complete this by adding some code to wait for the signed: true event (signing the transaction was successful) so we can get our long awaited user token to deliver our future sign requests with a Push notification.

When we run this code, open the payload URL on our smartphone, sign it with XUMM, your terminal should look like this. Note the User Token at the end 🎉

The user token is a unique token for your XUMM app in combination with the specific XUMM user. To use the token to deliver a sign requst per Push notification, let's adjust our first (minimal) sample payload to include the user token:

{
  "TransactionType": "Payment",
  "Destination": "rwietsevLFg8XSmG3bEZzFein1g8RBqWDZ",
  "Amount": "10000"
}

Please change the destination account to an account that you own (remember to use your destination tag if this is required), or if you wish, you can test by sending a small amount of XRP to the XRPL Labs team by using the account in the example.

This payload only contains the XRP ledger specific transaction template. Because we are now going to send XUMM platform specific information as well, we need to wrap the XRP ledger transaction template in an object called txjson. We can then add XUMM platform specific information to the payload as well, like options, custom_meta and the user_token.

Wrapping the XRP ledger transaction template in a txjson object, and adding the user_token property, our payload should now look like this:

{
  "txjson": {
    "TransactionType": "Payment",
    "Destination": "rwietsevLFg8XSmG3bEZzFein1g8RBqWDZ",
    "Amount": "10000"
  },
  "user_token": "..."
}

If we use the user token we received from our previously signed payload and use that in our code, you will see your sign request popping up on your smartphone. Well done!

Now we will run the code, keeping an eye on our smartphone:

When using this in applications, it would make sense to check the pushed property of a created payload. If False, the Push notification could not be sent (e.g., if permissions were revoked by the user) then your application should fall back to the QR method. If pushed is True, it makes sense to show the end user a button to show the QR code anyway if they didn't receive the push notification (eg. changed devices / other device).

Next:

5. Security & finishing touch 🎉