Send and Receive Payments

Most of the time, you’ll be sending money to someone else who has their own account. For this tutorial, however, you’ll need a second account to transact with. So before proceeding, follow the steps outlined in Create an Account to make two accounts: one for sending and one for receiving.

About Operations and Transactions

Actions that do things on Lantah — like sending payments or making buy or sell offers — are called operations. To submit an operation to the network, you bundle it into a transaction, which is a group of anywhere from 1 to 100 operations accompanied by some extra information, like which account is making the transaction and a cryptographic signature to verify that the transaction is authentic.

Transactions are atomic, meaning that if any operation in a transaction fails, they all fail. Let’s say you have 100 grams and you make two payment operations of 60 grams each. If you make two transactions (each with one operation), the first will succeed and the second will fail because you don’t have enough grams. You’ll be left with 40 grams. However, if you group the two payments into a single transaction, they will both fail and you’ll be left with the full 100 grams still in your account.

Every transaction also incurs a small fee. Like the minimum balance on accounts, this fee deters spam and prevents people from overloading the system. This base fee is very small — 100 Plancks per operation where a Planck equals 1 * 10 ^-7 GRAM — and it’s charged for each operation in a transaction. A transaction with two operations, for instance, would cost 200 Plancks.

Send a Payment

Lantah stores and communicates transaction data in a binary format called XDR, which is optimized for network performance but unreadable to the human eye. Luckily, Gravity, the Lantah API, and the Lantah SDKs convert XDRs into friendlier formats. Here’s how you might send 10 grams to an account:

What exactly happened there? Let’s break it down.

1 - Confirm that the account ID (aka the public key) you are sending to actually exists by loading the associated account data from the Lantah network. It’s okay to skip this step, but it gives you an opportunity to avoid making a transaction that will inevitably fail.

2 - Load data for the account you are sending from. An account can only perform one transaction at a time and has something called a sequence number, which helps Lantah verify the order of transactions. A transaction’s sequence number needs to match the account’s sequence number, so you need to get the account’s current sequence number from the network.

The SDK will automatically increment the account’s sequence number when you build a transaction, so you won’t need to retrieve this information again if you want to perform a second transaction.

3 - Start building a transaction. This requires an account object, not just an account ID, because it will increment the account’s sequence number.

4 - Add the payment operation to the account. Note that you need to specify the type of asset you are sending: Lantah’s network currency is the Gram, but you can send any asset issued on the network. We’ll cover sending non-Gram assets below. For now, though, we’ll stick to Grams, which are called “native” assets in the SDK:

You should also note that the amount is a string rather than a number. When working with extremely small fractions or large values, floating point math can introduce small inaccuracies. Since not all systems have a native way to accurately represent extremely small or large decimals, Lantah uses strings as a reliable way to represent the exact amount across any system.

5 - Optionally, you can add your own metadata, called a memo, to a transaction. Lantah doesn’t do anything with this data, but you can use it for any purpose you’d like. Many exchanges require memos for incoming transactions because they use a single Lantah account for all their users and rely on the memo to differentiate between internal user accounts.

6 - Now that the transaction has all the data it needs, you have to cryptographically sign it using your secret key. This proves that the data actually came from you and not someone impersonating you.

7 - And finally, submit it to the Lantah network!

In this example, we’re submitting the transaction to the SDF-maintained public testnet instance of Gravity, the Lantah API. When submitting transactions to a Gravity server — which is what most people do — it’s possible that you will not receive a response from the server due to a bug, network conditions, etc. In such a situation it’s impossible to determine the status of your transaction. That’s why you should always save a built transaction (or transaction encoded in XDR format) in a variable or a database and resubmit it if you don’t know its status. If the transaction has already been successfully applied to the ledger, Gravity will simply return the saved result and not attempt to submit the transaction again. Only in cases where a transaction’s status is unknown (and thus will have a chance of being included into a ledger) will a resubmission to the network occur.

In the above following samples, proper error checking is omitted for brevity. However, you should always validate your results, as there are many ways that requests can fail. You should refer to the guide on Handling Errors Gracefully for tips on error management strategies.

Receive a Payment

You don’t actually need to do anything to receive payments into a Lantah account: if a payer makes a successful transaction to send assets to you, those assets will automatically be added to your account.

However, you may want to keep an eye out for incoming payments. A simple program that watches the network for payments and prints each one might look like:

There are two main parts to this program. First, you create a query for payments involving a given account. Like most queries in Lantah, this could return a huge number of items, so the API returns paging tokens, which you can use later to start your query from the same point where you previously left off. In the example above, the functions to save and load paging tokens are left blank, but in a real application, you’d want to save the paging tokens to a file or database so you can pick up where you left off in case the program crashes or the user closes it.

Second, the results of the query are streamed. This is the easiest way to watch for payments or other transactions. Each existing payment is sent through the stream, one by one. Once all existing payments have been sent, the stream stays open and new payments are sent as they are made.

Try it out: Run this program, and then, in another window, create and submit a payment. You should see this program log the payment.

You can also request payments in groups or pages. Once you’ve processed each page of payments, you’ll need to request the next one until there are none left.

Transacting in Other Currencies

One of the amazing things about the Lantah network is that you can create, hold, send, receive, and trade any type of asset. Many organizations issue assets on Lantah that represent real-world currencies such as US dollars or Nigerian naira or other cryptocurrencies such as bitcoin or ether.

Each of these redeemable assets — anchored in the Lantah vernacular — is essentially a credit issued by a particular account that represents reserves those accounts hold outside the network. That’s why the assets in the example above had both a code and an issuer: the issuer is the public key of the account that created the asset, an account owned by the organization that ultimately honors the credit that asset represents. To find out more about how that works, check out Enable Deposits and Withdrawals.

Welcome

Introduction

Lantah Software Stack

Operations List

Tutorials

Create an Account

Send/Receive

Follow Received Payments

Handling Errors

Securing Web Projects

Run a Node
Overview

Prerequisites