Skip to main content

Dates & Timestamps

The PayConnect API uses a single, consistent convention for dates across customers, invoices, and subscriptions.

Responses: ISO-8601 UTC strings​

Every date field in a response is an ISO-8601 UTC date-time string, for example:

{
  "dueDate": "2026-04-01T12:00:00.000Z",
  "createdAt": "2026-03-15T14:37:05.123Z",
  "nextBillingDate": "2026-05-01T12:00:00.000Z"
}

This matches the convention transaction timestamps (processedAt, createdAt) have always used. Parse them with any standard date library (new Date(value), Date.parse(value), datetime.fromisoformat(...), etc.).

Fields affected include, across all resources: invoiceDate, dueDate, createdAt, updatedAt, nextBillingDate, firstBillingDate, currentPeriodStart, currentPeriodEnd, lastBillingDate, trialStart, trialEnd, endDate, cancellationDate, and delayedPostDate.

Requests: date-only or full ISO-8601​

Date inputs accept either form:

InputInterpreted as
Date-only "2026-04-01"Noon UTC of that day — 2026-04-01T12:00:00.000Z
Full ISO-8601 "2026-04-01T09:30:00.000Z"That exact instant
Epoch milliseconds 1743508800000 (where a field documents it)That exact instant

Why noon UTC for date-only values​

A date-only value such as "2026-04-01" is anchored to noon UTC, not midnight. Midnight UTC renders as the previous calendar day in any negative (US) timezone, so an invoice due 2026-04-01 could display as 03/31. Anchoring to noon keeps the rendered calendar day stable across every US timezone. Invoices and subscriptions use the same rule, so identical date-only input produces the same instant on both.

Search filters accept the same input forms. For an eq filter on a date field with a date-only or date-string value, the match is the whole UTC calendar day that contains it (a date-only value bounds its literal day; a datetime value bounds the UTC day of that instant). Supplying an explicit epoch-ms number with eq keeps exact-millisecond matching.

Provider passthrough fields (exceptions)​

A few fields mirror the payment provider's own representation verbatim and are not normalized:

  • Saved payment method / account vault created_ts and modified_ts are epoch seconds (not milliseconds), passed through from Fortis.
  • Card exp_date is MMYY (e.g. "1226" for December 2026).

These are documented on the individual payment-method endpoints; everywhere else, dates follow the ISO-8601 convention above.