Attach string key-value pairs to payment requests with the data object on WidgetConfig. Values are forwarded to the Paysight API with each payment attempt (card, wallet, upsell). Some keys receive dedicated attribution handling. Other keys are sent as payment props; forwarding does not guarantee persistence or availability in transaction APIs.
Basic usage
Common keys
Do not use campaignId or affiliateId for your own identifiers. These deprecated fields accept only internal, Paysight-assigned IDs. Unknown values can cause the payment request to be rejected. Use campaignName and affiliateName instead.
Playground data shape
The Widget Playground starts with campaign, utm_source, and url rows to demonstrate generic custom metadata. The campaign key is not the dedicated Paysight campaign field. Use campaignName when you want Paysight campaign attribution, and use affiliateName for affiliate or traffic-source attribution.
Attribution across upsells
The same Paysight product and initial payment session are reused across the journey. Once campaign/affiliate attribution is established, changing data.campaignName or data.affiliateName on later widget instances does not reliably override it. The transaction table returns resolved campaign and affiliate values. These names are not reliable per-offer product labels.
upsellId, sub-affiliate identifiers, click identifiers, UTM values, and arbitrary custom data keys are not exposed as dedicated fields by the current transaction list/detail APIs. Generic custom keys are not guaranteed to be stored per transaction. Keep your own offer-to-payment records if you need item-level identification. See Saved payment & upsell.
Updating at runtime
UTM capture pattern
data values must be strings (Record<string, string>). Coerce numbers before passing.
Distinction from session IDs