Skip to content

[DBIP] Normalize ramp deliveryType as a JSON list #3119

Description

@nightmare28899

Proposal type

Modify column

Affected scope (files/folders/chains)

references/offers/ramps.csv; inherited deliveryType values in listings/all-networks/ramps.csv and listings/specific-networks/*/ramps.csv; Ramps wiki column definition

Motivation / problem statement

The Ramps wiki defines deliveryType as one free-text value, but ramp products commonly expose several integration surfaces. In the current main snapshot (commit 51cdb41), all 64 ramp offers have a value, with these results:

  • 22 API
  • 22 TBD
  • 8 Widget
  • 3 Web app
  • 9 multi-surface rows encoded with seven incompatible strings, including API,Widget, API, Widget, Widget/API, API, white-label widget, API, White Label, Web, Unified Checkout, API, and Web / App / Physical branch

This makes exact filtering unreliable: a consumer searching for API integrations finds API but misses Widget/API and the other composite forms. It also encodes delimiters, capitalization, and whitespace as data. The 22 TBD values conflict with the Style Guide rule that reserves TBD for internal transitional schema rollouts.

Developers comparing embedded widgets, APIs, hosted checkout pages, apps, and physical access points benefit from a normalized multi-value field.

Detailed proposal

  • Category/table: ramps
  • Column name: deliveryType
  • Change type: modify
  • New definition: one or more normalized surfaces through which a user or developer consumes the ramp. Leave blank when unverified; do not use TBD.
  • Value type: JSON array of enum values
  • Initial allowed values:
    • Web app
    • Mobile app
    • Desktop app
    • API
    • Widget
    • SDK
    • White-label
    • Physical branch
  • Examples:
    • API-only integration: ["API"]
    • hosted widget plus API: ["Widget","API"]
    • configurable partner product: ["API","White-label"]
    • consumer access in several channels: ["Web app","Mobile app","Physical branch"]
  • Normalization guidance:
    • Store each surface once and use the exact vocabulary above.
    • Do not join values with commas or slashes.
    • Describe branded flows such as “Unified Checkout” in an existing descriptive/tag field while mapping their delivery surface here.
    • Replace TBD with verified values or blank.
    • Add a new enum value only through a documented schema update.

The change is backward-manageable through the existing canonical offer inheritance: migrate the 64 canonical offer cells, then remove any equivalent listing overrides if present.

Contact (optional)

GitHub: @nightmare28899

Rewards address (optional)

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    DBIPFor database improvement proposals

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions