This NIP standardizes the approach to payment and tip invocations from user profiles, posts, chats, and elsewhere using the [RFC-8905 (payto:) URI scheme](https://www.rfc-editor.org/rfc/rfc8905.html) standard for "payment targets".
Clients *may* allow users to specify a list (one or many) of "payment targets" as specified in the [RFC-8905 (payto:) URI scheme](https://www.rfc-editor.org/rfc/rfc8905.html) standard, each consisting of a pair of values, `payment_target_type` and `authority` (to be labeled as preferred by the client), in order to generate an event of kind `0` (`set_metadata`) specifying "payment targets" that *may* be used for payment or tip invocation from a user's profile, posts, chats, or elsewhere.
The client *may* allow the user to input and perform validation on the `payment_target_type` and `authority` fields (labeled as preferred by the client) as they see fit.
### Example of broadcasting a "payto" event
The client allows the user to add multiple pairs of "payment network" and "address" values to a list of "payment options" in their profile.
The client performs validation on the inputs and warns the user that the "payment network" for the third "payment option" with value `unknowntype` is [not recognized](#recommended-payment-target-types), but allows them to submit it regardless.
On observation of events of kind `0` (`set_metadata`), the event *may* specify the key `"payto"` with a value consisting of a list (one or many) of "payment target" values, each specified as a pair of values `payment_target_type` and `authority` as specified in the [RFC-8905 (payto:) URI scheme](https://www.rfc-editor.org/rfc/rfc8905.html) for payment targets.
For each pair of values in the `payto` list, the client *should* assemble a full `payto://` deep link URI and render it as a button or link in the user's profile, posts, chats, or elsewhere, in the format of `payto://<payment_target_type>/<authority>`.
The client *should* store a map of [recognized payment target types](#recommended-payment-target-types) along with a corresponding icon & stylization configuration (to be defined by the client).
For ***unrecognized*** `payment_target_type` values, the client *may* chose to either ignore them or use a generic stylization, perhaps using the `payment_target_type` value directly for the button or link.
If a user has specified multiple payment targets, the client *may* choose to render only the first one, render multiple buttons or links, or render a dropdown to select the payment target of choice.
The client chooses to ignore the third *unrecognized*`payment_target_type`, and only embeds the first two payment target deep links in the user's profile, posts, chats, or elsewhere as buttons, links, or a dropdown selector using the corresponding icons & stylizations for the [*recognized* payment target types](#recommended-payment-target-types).
#### Example of steps taken by the client on observation
- for each pair of `payment_target_type` and `authority` values in the `payto` list
- *optionally* do some minimal validation on those fields in a generalized way that applies to any payment network, and filter out invalid pairs
- *optionally* filter out any pairs with an [*unrecognized*](#recommended-payment-target-types) `payment_target_type`
- assemble a full `payto://` deep link URI in the format `payto://<payment_target_type>/<authority>`
- render a button, link, or dropdown in user profiles, posts, chats, and elsewhere using the assembled deep links and the corresponding icons & stylization configurations for *recognized*`payment_target_type` values
