Skip to main content

​
Dynamic Links

A dynamic link is a payment link without a fixed amount. The buyer enters the amount they wish to pay before selecting a payment method.
  • Donations: Let supporters choose their contribution amount.
  • Tips or gratuities: Let customers decide how much to tip.
  • Flexible invoicing: When the amount varies per transaction.
  • Pay-what-you-want: For products or services with flexible pricing.
Omit the amount field from the request:
The response includes expires_at (null when no TTL is set):
When the buyer opens the link, they see an amount input field before proceeding to payment method selection.
The only difference between a regular payment link and a dynamic link is whether you include the amount field in the request. Everything else — response format, webhooks, redirects, TTL — works the same way.
Dynamic links support the same ttl_minutes parameter as fixed-amount links. See the Payment Links overview for full details on expiration behavior, including in-flight payment handling. GET /v1/links/public/:hash returns the link’s current state, including expiration:
If the link is inactive or expired, the endpoint returns 410 with PAYMENT_LINK_INACTIVE or PAYMENT_LINK_EXPIRED respectively.

​
Collecting shopper contact data

By default, dynamic links only ask buyers for the information their payment method requires (phone number for Nequi, national ID for Daviplata, etc.). If you need the buyer’s name, email, or phone number to identify the payer in your backoffice, use the user_data_required flag (or the legacy collect_shopper_data alias):
When this flag is true, the checkout page shows a contact form (first name, last name, email, phone) before the buyer proceeds to payment method selection. The submitted data is stored with the order.

​
Behavior

​
Field reference

​
Rules

  • user_data_required is valid on both dynamic and fixed-amount links.
  • If omitted: dynamic links default to false; fixed-amount links default to true.
  • The resolved value is returned by GET /v1/links/public/:hash as user_data_required (boolean), so the checkout never needs to infer the default.
Use collect_shopper_data when you need to reconcile payments against a known buyer (e.g., donations, event registrations) and your payment gateway alone doesn’t provide enough buyer identification.