Custom fields: capture the data your business actually needs
Most payment platforms give you a fixed schema: name, email, amount, status. If your business needs anything beyond that, you end up maintaining a spreadsheet alongside your transaction data, or building a fragile side table in your CRM. EPD Commerce custom fields close that gap.
Custom fields let merchants define structured data fields on customers, payments, and subscriptions, then read and write those fields through the same API surface they already use for everything else.
What custom fields do and who they help
Custom fields are built for two groups of users simultaneously: operators who need to capture business-specific data without involving a developer, and technical builders who need that data to flow reliably through API responses and webhook payloads.
A concrete example: a merchant with a sales team wants to attribute each subscription to the rep who closed it. Without custom fields, that means a manual lookup table somewhere outside the platform. With custom fields, they add a “Salesperson” single-select field to subscriptions. Every subscription.created webhook carries the rep’s name. Every reporting or automation tool downstream receives it automatically.
Field types and supported objects
Custom fields support four types:
- Text input: free-form strings, suitable for internal notes, reference numbers, or identifiers
- Single select: one value from a defined option list
- Multi select: one or more values from a defined option list
- User record reference: links the field value to an existing user record in the platform
Fields can be attached to three object types: customers, payments, and subscriptions. Once a field is created on an entity, it appears across Easy Charge, hosted checkout, object creation screens, object edit screens, and the relevant detail views.
How the key system works
Every custom field gets a stable, immutable key that serves as its API identifier. The key is auto-generated from the field name at creation time: “Salesperson” becomes salesperson, for example. A merchant can edit the key before saving the field for the first time. After first save, the key is locked.
This matters for integrations. A merchant can rename the display label later without breaking any downstream system that keys off salesperson. The API and webhooks always use the key, never the label.
Key format follows SKU rules: latin letters, digits, underscores, and hyphens only; not case-sensitive; 20-character maximum. Duplicate auto-generated keys receive a unique suffix automatically, so collision handling is not a manual task.
Two things cannot change after a field is created: its type and its entity. Changing a type after integrations are built against it would silently break data expectations in downstream systems. Locking both at creation is the correct engineering tradeoff.
API and webhook surface
Custom field values flow through the existing API endpoints rather than requiring new endpoints for every operation. The write and read shape uses a simple key-value map:
"custom_fields": {
"salesperson": "Jason Williams"
}The definition API, used when you need to inspect field metadata (visibility, required status, available options), returns an extended structure:
"custom_fields": [
{
"key": "salesperson",
"name": "Salesperson",
"type": "single_select",
"required": false,
"value": "Jason Williams"
}
]The Retrieve Custom Fields API returns active fields only, with full metadata. Internal IDs are not exposed; only the external key is returned.
Supported webhook events that carry custom field values: order.created, subscription.created, customer.created, and customer.updated.
Affected API endpoints span Customer (create, update, retrieve), Order (create, retrieve), Subscription (create, update, retrieve), and Product and Plan (retrieve).
No developer involvement required for field management
Merchants create, edit, disable, and delete custom fields entirely through the platform UI. There is no need to open a support ticket or touch configuration files. The experience is consistent across mobile and desktop. The design follows the EPD Commerce platform design system, so custom fields look and behave like every other field in the interface.
This is important for operators who run automations through tools like Zapier or Make: they can define the fields they need, wire them into their automation, and iterate without waiting on engineering.
FAQ
What are EPD Commerce custom fields? EPD Commerce custom fields are user-defined data fields that merchants can add to customer records, payments, and subscriptions. They support four field types (text input, single select, multi select, and user record reference) and flow through the platform’s API and webhook payloads automatically.
Do I need a developer to create or manage custom fields? No. Merchants create, edit, disable, and delete custom fields through the EPD Commerce dashboard UI, without any developer involvement. Developers can interact with custom field values through the existing API surface if they are building integrations or automations.
How do custom fields appear in the API and webhooks? Custom field values are included in supported webhook events and API responses using a simple key-value map. The key is a stable, immutable identifier generated from the field name at creation. It does not change when a merchant renames the field’s display label, so downstream integrations remain stable.
Can I change a custom field’s type after I create it? No. Field type and the entity the field is attached to are both locked after creation. This is intentional: changing a type after an integration has been built against the field would break downstream data handling without any visible error.
What is the main use case for custom fields in automations? The primary pattern is attribution and cross-platform reporting. A merchant attaches a structured field (like “Salesperson” or “Campaign Source”) to subscriptions or orders. Every webhook that fires for those objects carries that field value, so reporting tools, CRMs, and automation platforms receive the data without any manual lookup or export step.
EPD Commerce is currently in Beta ahead of its October public launch. To see custom fields in context, request Beta access at epd.com.