Proposal type
Modify column
Affected scope (files/folders/chains)
references/offers/ramps.csv; inherited paymentMethods values in listings/all-networks/ramps.csv and listings/specific-networks/*/ramps.csv; Ramps wiki definition; shared CSV/schema validation for this field.
Motivation / problem statement
paymentMethods is already stored as a JSON array, so it looks machine-filterable, but the values are currently an undocumented open vocabulary. Current main contains multiple levels of abstraction and multiple naming conventions in the same field, including:
generic methods: card, bank_transfer
card subtypes: credit_card, debit_card
bank rails/schemes: ach, sepa, swift, wire, fps, rtp, eft, pix, spei, upi
branded methods: paypal, revolut_pay, gcash, paymaya, skrill, neteller
free-form values containing spaces or punctuation such as revolut account and SMS/USSD wallet
catch-all values such as local_payment_methods
at least one apparent spelling defect in the canonical data: exchange_balancies
The field therefore has structure at the JSON level but not at the vocabulary level. A consumer cannot safely do an exact filter without knowing every historical spelling and abstraction choice. The current validator also cannot distinguish a new legitimate method from a typo.
This is separate from the open proposals for ramp direction, fiat currencies, country availability, delivery type, and price. Those describe different dimensions; this proposal only makes the existing paymentMethods field deterministic.
Detailed proposal
Category/table: ramps
Column name: paymentMethods
Change type: modify
New/updated definition: JSON array of canonical payment-method identifiers supported by the ramp. Each identifier represents one payment method or named payment rail, using a documented stable token.
Value type: JSON array of enum strings.
Normalization rules:
Use lowercase snake_case identifiers only.
Keep distinct rails distinct when the provider explicitly documents them (ach, sepa, fps, pix, spei, upi, etc.).
Keep a generic value only when the source is genuinely generic. For example, card remains valid when the provider says only “card”; use credit_card / debit_card when those are explicitly distinguished.
Branded methods use canonical identifiers, e.g. revolut_account rather than revolut account.
Multi-channel labels must be one canonical token rather than free-form punctuation, e.g. sms_ussd_wallet rather than SMS/USSD wallet.
Keep a documented catch-all such as local_payment_methods only when the provider itself exposes a variable set that cannot be enumerated reliably.
Values must be unique within the array. Unknown identifiers should fail validation until the documented enum is extended.
Do not silently “correct” a value whose meaning is unclear. The current exchange_balancies cell should be re-verified against first-party documentation before being migrated.
Suggested initial migration examples:
revolut account -> revolut_account
SMS/USSD wallet -> sms_ussd_wallet
leave already canonical values such as bank_transfer, credit_card, debit_card, ach, sepa, pix, upi, paypal unchanged
Validation:
assert paymentMethods parses as a JSON array when non-blank;
reject duplicate elements;
reject tokens outside the documented allowlist;
reject whitespace, slash-separated prose, and non-canonical case;
report path, row, and offending token.
Migration should be evidence-first: mechanically migrate only unambiguous formatting aliases, then review ambiguous values against first-party sources. No provider capability should be inferred from another provider or from geography.
Why an enum instead of leaving free text: this field is already intended for structured filtering. A controlled vocabulary preserves that intent while still allowing new methods through an explicit schema/wiki update rather than accidental spelling drift.
I am happy to implement the validator and a separately reviewable cleanup PR if this proposal is accepted.
Method disclosure: prepared with AI assistance; current repository data and existing DBIP search were checked before submission.
Contact (optional)
GitHub: @karankad95
Rewards address (optional)
0xc37fe35e8Dc8975b73743847b681C80E149d0F6f (Ethereum mainnet USDC/USDT)
Proposal type
Modify column
Affected scope (files/folders/chains)
references/offers/ramps.csv; inherited paymentMethods values in listings/all-networks/ramps.csv and listings/specific-networks/*/ramps.csv; Ramps wiki definition; shared CSV/schema validation for this field.
Motivation / problem statement
paymentMethods is already stored as a JSON array, so it looks machine-filterable, but the values are currently an undocumented open vocabulary. Current main contains multiple levels of abstraction and multiple naming conventions in the same field, including:
generic methods: card, bank_transfer
card subtypes: credit_card, debit_card
bank rails/schemes: ach, sepa, swift, wire, fps, rtp, eft, pix, spei, upi
branded methods: paypal, revolut_pay, gcash, paymaya, skrill, neteller
free-form values containing spaces or punctuation such as revolut account and SMS/USSD wallet
catch-all values such as local_payment_methods
at least one apparent spelling defect in the canonical data: exchange_balancies
The field therefore has structure at the JSON level but not at the vocabulary level. A consumer cannot safely do an exact filter without knowing every historical spelling and abstraction choice. The current validator also cannot distinguish a new legitimate method from a typo.
This is separate from the open proposals for ramp direction, fiat currencies, country availability, delivery type, and price. Those describe different dimensions; this proposal only makes the existing paymentMethods field deterministic.
Detailed proposal
Category/table: ramps
Column name: paymentMethods
Change type: modify
New/updated definition: JSON array of canonical payment-method identifiers supported by the ramp. Each identifier represents one payment method or named payment rail, using a documented stable token.
Value type: JSON array of enum strings.
Normalization rules:
Use lowercase snake_case identifiers only.
Keep distinct rails distinct when the provider explicitly documents them (ach, sepa, fps, pix, spei, upi, etc.).
Keep a generic value only when the source is genuinely generic. For example, card remains valid when the provider says only “card”; use credit_card / debit_card when those are explicitly distinguished.
Branded methods use canonical identifiers, e.g. revolut_account rather than revolut account.
Multi-channel labels must be one canonical token rather than free-form punctuation, e.g. sms_ussd_wallet rather than SMS/USSD wallet.
Keep a documented catch-all such as local_payment_methods only when the provider itself exposes a variable set that cannot be enumerated reliably.
Values must be unique within the array. Unknown identifiers should fail validation until the documented enum is extended.
Do not silently “correct” a value whose meaning is unclear. The current exchange_balancies cell should be re-verified against first-party documentation before being migrated.
Suggested initial migration examples:
revolut account -> revolut_account
SMS/USSD wallet -> sms_ussd_wallet
leave already canonical values such as bank_transfer, credit_card, debit_card, ach, sepa, pix, upi, paypal unchanged
Validation:
assert paymentMethods parses as a JSON array when non-blank;
reject duplicate elements;
reject tokens outside the documented allowlist;
reject whitespace, slash-separated prose, and non-canonical case;
report path, row, and offending token.
Migration should be evidence-first: mechanically migrate only unambiguous formatting aliases, then review ambiguous values against first-party sources. No provider capability should be inferred from another provider or from geography.
Why an enum instead of leaving free text: this field is already intended for structured filtering. A controlled vocabulary preserves that intent while still allowing new methods through an explicit schema/wiki update rather than accidental spelling drift.
I am happy to implement the validator and a separately reviewable cleanup PR if this proposal is accepted.
Method disclosure: prepared with AI assistance; current repository data and existing DBIP search were checked before submission.
Contact (optional)
GitHub: @karankad95
Rewards address (optional)
0xc37fe35e8Dc8975b73743847b681C80E149d0F6f (Ethereum mainnet USDC/USDT)