Stellar payments — thoughts on federation, QR Codes, URIs, and Point of Sale systems within the Stellar.org ecosystem

Published in

Lumenauts

7 min readJul 9, 2018

Stellar, like almost all encryption systems and blockchain payments works with Public-key cryptography(1) that was invented in the 1970s where the public key is the address where you receive funds. Early on Stellar supported human style names that look like anthony*tempo.eu.com, +33123123*tempo.eu.com and jsmith@gmail.com*tempo.eu.com with a system called federation(2) which does a simple https get to pull information.

This is great as it easier to type and remember than the stellar public key which looks something like:

GC2BQYBXFOVPRDH35D5HT2AFVCDGXJM5YVTAF5THFSAISYOWAJQKRESK

Smart anchors such as flutterwave.com have used federation with the format account_number.swiftcode*flutterwave.com. When a wallet does a federation lookup flutterwave validates the bank account number and swift code. Quite cool and is much more simple and less expensive than ethereum’s lookup system called Ethereum ENS.

Bitcoin implemented bip 0021 in 2012 (3), which is used for payments. It looks a bit like a uri and can be used as one as was registered with iana.org (4). It can also be converted to a QR code.

bitcoin:175tWpb8K1S7NmH4Zx6rewF9WQrcZv245W?amount=20.3

In the Stellar world the first few wallets also supported QR code conversion and with a bit of prodding Centaurus, Lobstr, Stargazer, Papaya all currently work well together.

As a barcode this would look quite long in 128 Encoding

With stellar most wallets just used public key with no additional data initially.

This was a good start but were are some missing items. The first is MEMO fields that are typically used by both exchanges and certain wallets. Other items are the amount and asset type.

One way wallets addressed this was to create a more complex qr code as defined in Stargazer wallet or as extended by sacarson (5).

{
    "stellar": {
        "payment": {
            "destination":  ACCOUNT_ID,
            "network":      NETWORK_CODE, // (*)
            "amount":       AMOUNT,
            "asset": {      // (**)
                "code":     ASSET_CODE,
                "issuer":   ASSET_ISSER
            },
            "memo": {       // (***)
                "type":     MEMO_TYPE,
                "value":    MEMO
            }
        }
    }
}

Another way might be to just use the federated address as a QR code. Shorter URIs makes QR decoding more stable. A camera with a scratched lens or low resolution may run into problems scanning huge QR codes.

payto://stellar/orderid*store.tempo.eu.com?amount=EURT:200.0

Using google to create the qr code:

In this case the details of the asset (key, decimals,image) are listed in the stellar.toml on the website. This has a lot less characters and leverages this payto IETF proposal(6) from earlier this year. Stellar wallets would need to use a path payment in the event that the person does not trust or hold the asset that needs to be submitted.

I believe it looks more elegant than Bitcoin’s BIP-072’s payment format:

bitcoin:mq7se9wy2egettFxPbmn99cK8v5AFq55Lx?amount=0.11&r=https://merchant.com/pay.php?h%3D2a8628fc2fbe

URIs could also be registered with Android as an intent (9) or on Iphone as a URL Schema or an app extension so that when a user clicks on the link in an email or chat it would open a crypto wallet with the required information.

The first issue with this is we need to get wallets to all support a new standard. If we see what happened with Ethereum there have been years of debates on EIP 67 and 681(8). Also as a URI it doesn’t help with confused deputy problems such as CSRF attacks (if you use it as a URL not QR code), man in the middle attacks, underpayment issues or network fees (if stellar fees became substantial).

Mike Hearn and Gavin Andresson came up with the Bitcoin Payment Protocol specification BIP-0070 to deal with these issues. It consists really of just 3 calls: PaymentRequest, Payment, and PaymentACK. However some wallets found the implementation hard as as they relied on non bitcoin style x.509 certificates to verify companies and protocol buffers for data serialisation.

Bitpay rewrote the Bitcoin Payment Protocol specification and released it in February (9) this year, simplifying it by moving to the JSON format instead of protocol buffers and using pgp for validation of the merchant. They claim to have seen a 20 fold reduction in payment errors(10) since pushing wallets to support BIP-0070 earlier in the year.

In the Stellar universe we already have the XDR format which is an old great standard. This article from Scott Locklin outlines why this was a good choice.

Please stop writing new serialization protocols

It seems that every day, some computer monkey comes up with a new and more groovy serialization protocol. In the…

scottlocklin.wordpress.com

Along comes Stellar standard SEP-007

In May 2018, lightyear proposed the new Stellar SEP-007 (11) “URI Scheme to facilitate delegated signing” which on first read through looks to be made to help delegated signing of transactions. This would help decentralised applications to process transactions without having access to a users private key (applications like the upcoming StellarX) or the stellarport.io trading app. However it also contains a payment URI scheme:

web+stellar:pay?destination=GCALNQQBXAPZ2WIRSDDBMSTAKCUH5SG6U76YBFLQLIXJTF7FE5AX7AOO&amount=100.123&asset_code=EURT&asset_issuer=GAP5LETOV6YIE62YAM56STDANPRDO7ZFDBGSNHJQIYGGKSMOZAHOOS2S&memo=tempo&callback=url%3Ahttps%3A%2F%2FsomeSigningService.com%2Fhasysda987fs%3Fasset%3DUSD

On closer analysis the specification contains much of the components of the Bitcoin Payment Protocol (BIP-0070) and putting together an extended and comparable specification should be fairly easy. Such a specification should include stellar federation, the PaymentACK callback function, refund addresses, decimals, network fees, and the handling of merchant orderids.

What about the W3C payments spec? The World Wide Web consortium has a draft Payment Request API (12) which was released a month ago. Reading through this large set of documentation you can see that it is primarily targeted at shipping of physical products and credit card handling. Basically their goal is to make entering address information easier for online merchants. It does not really support URI/QR codes at all. From my perspective the Bitcoin payment protocol looks far more simple.

A final way as a Stellar “hack” you could do is to generate public keys for each transaction and then merge them into the main key once the funds were received. In effect this is how exchanges like Shapeshift handle transactions and would work with all stellar wallets now.

POS — Point of Sale

China is the king of Mobile payment systems and typically for non card based mobile payments systems they use QR Codes and integrate in one of 3 ways. As this is a closed system many of the security concerns related to web based of open payments are reduced.

Merchant scanning: where the client shows a qr code to the merchant and a random transaction number is displayed. Advantages are that the mobile app need not have internet access as long as it generates a random qr code and there is a “pull style” transaction where the merchant can pull from the person’s account. This would not be easy to do on Stellar currently but may be with SEP-007 and and an online wallet.
Customer Scan: Customers scans the merchant public key QR code and then input the amount to make the payment. The merchant’s system then gets notification of the payment. This works right now with merchant integration.
Dynamic QR Customer Scan: For this the app generates a dynamically produced QR code to represent a transaction. The customer doesn’t need to input the transaction amount, but scans the generated QR code to complete the payment. This works right now. In the stellar world this could be done using the QR code spec from dzham or SEP-007.

Retail is very important in last mile of the payments ecosystem. Stellar.org blockchain supports 3–5 second settlement times and 1000s of tx per second which could work right now for global retail payments without having to resort to layer 2 systems such as the lightening network.

TEMPO, a EU based Stellar Anchor is launching a coin event shortly to drive out further value in the crypto-payments space. Visit https://tempocrypto.com for more information.

(1) https://en.wikipedia.org/wiki/Public-key_cryptography

(2) https://www.stellar.org/developers/guides/concepts/federation.html

(3)https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki

(4) https://www.iana.org/assignments/uri-schemes/prov/bitcoin

(5) https://github.com/future-tense/stargazer/blob/master/docs/qr-codes.md

https://github.com/sacarlson/sacarlson.github.io/blob/master/qr-code_extention.md

(6) https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki

(7) https://tools.ietf.org/html/draft-dold-payto-01

(8) https://github.com/ethereum/EIPs/pull/681

(9) http://www.vogella.com/tutorials/AndroidIntent/article.html

(10) https://blog.bitpay.com/payment-protocol-results/
https://github.com/bitpay/jsonPaymentProtocol

(11) https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0007.md