Lib.rs

These days, there are many possible ways to communicate Bitcoin payment instructions. This crate attempts to unify them into a simple parser which can read text provided directly by a payer or via a QR code scan/URI open and convert it into payment instructions.

This crate doesn't actually help you pay these instructions, but provides a unified way to parse them.

Payment instructions come in two versions -

• ConfigurableAmountPaymentInstructions represent instructions which can be paid with a configurable amount, but may require further resolution to convert them into a FixedAmountPaymentInstructions for payment.
• FixedAmountPaymentInstructions represent instructions for which the recipient wants a specific quantity of funds and needs no further resolution

In general, you should resolve a string (received either from a QR code scan, a system URI open call, a "recipient" text box, or a pasted "recipient" instruction) through PaymentInstructions::parse.

From there, if you receive a PaymentInstructions::FixedAmount you should check that you support at least one of the FixedAmountPaymentInstructions::methods and request approval from the wallet owner to complete the payment.

If you receive a PaymentInstructions::ConfigurableAmount instead, you should similarly check that that you support one of the ConfigurableAmountPaymentInstructions::methods using PossiblyResolvedPaymentMethod::method_type, then display an amount selection UI to the wallet owner. Once they've selected an amount, you should proceed with ConfigurableAmountPaymentInstructions::set_amount to fetch a finalized FixedAmountPaymentInstructions before moving to confirmation and payment.

This crate contains a basic parser for Bitcoin Payment Instructions.

It supports various encodings which you might encounter in QR codes, typed/pasted into a text box, or opened via a system URI handler.

Any missing Payment Instruction formats should be added as soon as there is a standard encoding for address formats, ideally using a Rust crate that (a) has very minimal dependencies, (b) has a fairly conservative MSRV policy, and (c) has regular contribution from more than one individual.