Receivable

receivable is the claim Repejo tracks against a payer, either as a one-time payment or as part of a subscription. It is the main entity for a gift or payment — the amount that should be collected.

A receivable can have many transactions. Each transaction is one attempt to satisfy the receivable: if the first attempt fails (for example insufficient funds or a rejected charge), Repejo creates a new transaction for the next attempt against the same receivable. The receivable is considered paid once one of its transactions succeeds.

Draft: The documented REST endpoints for receivable are planned but not exposed in the router. Webhook events are the integration surface that is active today.

Payload

type ReceivableID = `rec_${string}`;
type ReceivablePaymentMethod =
| "swish"
| "autogiro"
| "card"
| "apple_pay"
| "google_pay"
| "stripe_subscription"
| "sepa_direct_debit"
| "invoice"
| "offline"
| "none";

type Receivable = {
id: ReceivableID;
amount: string;
message_from_payer: string | null;
status: "paid" | "unpaid" | "terminated_by_payer";
type: "onetime" | "recurring";
payment_method: ReceivablePaymentMethod | null;
transaction_date: string;
paid_at_date: string | null;
reference: string | null;
payer_id: PayerID;
subscription_id: SubscriptionID | null;
product_type:
| "donation"
| "membership"
| "gift_card"
| "p2p"
| "physical"
| "lottery"
| "live";
metadata: Record<string, string>;
external_transaction_id: string | null;
paid_at: string | null; // ISO 8601 UTC, e.g. "2026-04-20T10:00:00Z"
payer: Payer | null;
};

transaction_date is the due date for the receivable. For donations, paid_at_date is used for display in the interface when present, but both fields exist in the model.

paid_at is the moment the receivable was paid, as an ISO 8601 UTC timestamp, and is null while the receivable is unpaid. Its precision depends on the payment rail: for Swish, card, Apple Pay, Google Pay and invoice payments it is the instant the payment was confirmed (second precision). For Autogiro/Bankgiro, Stripe subscriptions and offline payments only the settlement date is known, so paid_at is 12:00:00 Europe/Stockholm on paid_at_date, expressed in UTC (10:00:00Z in summer, 11:00:00Z in winter). The value is derived when the event is created and frozen into the delivery; a resent event replays the value from the original send.

The field set above is the complete payload for every receivable webhook; all fields are always present. external_transaction_id holds the external id of the receivable's paid transaction (for example a Stripe charge or a Swish payment) and is null when no such transaction exists.

Planned endpoints

  • GET /api/receivables
  • GET /api/receivables/:id
  • POST /api/receivables

receivable and transaction are not the same entity under different names. receivable.created and receivable.updated carry the receivable described above. Each payment attempt against a receivable is a separate transaction, delivered via transaction.created and transaction.updated. See the Transaction page for that payload.