Digistore24

ISFY consumes Digistore24's standard IPN natively — no custom payloads, no transformation layer. Digistore24 vendors are live on ISFY in production today; a marketplace-native integration is mostly a provisioning question, not a data one.

How it works today — per-vendor IPN

POST {BASE_URL}/webhooks/digistore/{CONNECTION_TOKEN}

Content-Type: application/x-www-form-urlencoded   // standard Digistore24 IPN body

Routing: {CONNECTION_TOKEN} is an opaque per-vendor key we issue — it maps the delivery to the right vendor account on our side.
Authentication: we verify the SHA-512 sha_sign on every payload with the per-vendor IPN passphrase — the exact signing algorithm from the Digistore24 IPN documentation.
Response: 200 OK in well under a second.
Retries: safe at any time — we de-duplicate on order_id, so resends never create duplicates.
Backfill: we also use the Connection API (X-DS-API-KEY, listPurchases) for backfill and gap-recovery, within Digistore24 rate limits.

IPN events we consume

IPN event	What we do with it
`of_filled_out`	Abandoned order form → recovery dial queue. The highest-value event: an agent calls within minutes.
`on_payment`	Completed order — flips the earlier lead to completed, records revenue, feeds buyer/upsell campaigns.
`on_payment_missed`	Failed initial payment → payment-recovery dial queue.
`on_rebill_missed`	Missed subscription rebill → churn-recovery dial queue.
`on_refund` / `on_chargeback`	Recorded against the existing order; the original paid amount is preserved.
`on_rebill_resumed` / `on_pending_completed` / `on_affiliation`	Recorded on the order history.
anything new	Accepted — unknown event names are forward-compatible, nothing is rejected.

Fields we read

All standard IPN field names — nothing custom. Everything else in the payload rides along and is kept.

Field	Required?	Notes
`order_id`	Required	De-dupe and linking key — a later `on_payment` with the same id completes the earlier lead instead of duplicating it.
phone	Required in practice	First non-empty of `address_phone_no` / `address_mobile_no` / `billing_phone_no` / `billing_mobile_no`. Leads without a dialable number are skipped by design. Phone capture on the order form is the single biggest success factor.
`buyer_email`	Recommended
names	Recommended	`address_first_name` / `address_last_name` preferred (what the buyer typed at checkout), `buyer_*` as fallback.
`amount` + `currency`	Recommended	`amount` (net) preferred, `amount_brutto` fallback. On payment events this is the recorded revenue.
address	Optional	Street (single-line or number + name), city, state, zip, country.
`merchant_id` / `merchant_name`	Recommended	Vendor identity inside the payload.

What a marketplace-native integration needs

The data path already works — what's manual today is the handshake: each vendor pastes our IPN URL and passphrase into their Digistore24 settings by hand. For an "Enable ISFY" experience on the Digistore24 platform, either flow works for us:

Connect-flow redirect: the vendor clicks Enable ISFY in Digistore24 → is redirected to an ISFY connect page → we provision their connection and hand the IPN URL + passphrase back (to the vendor, or programmatically to Digistore24 if IPN settings can be set via API).
Server-to-server provisioning: Digistore24 calls an ISFY provisioning endpoint with the vendor's id and contact details; we respond with the per-vendor ipn_url and sha_passphrase, and Digistore24 registers the IPN on the vendor's behalf.

We'll build to whatever the Digistore24 integration-partner framework expects — send us the spec and we'll match it.

Prefer clean JSON instead? If reusing IPN isn't the natural fit for platform-level integrations, the generic Events API (JSON push) is equally supported — several platform partners use it in production.

Going live — the checklist

Digistore24 sends integration-partner requirements (listing process, connect-flow spec, whether IPN settings are settable via API).
We agree the provisioning flow — redirect or server-to-server — and build our side.
Pilot with one test vendor account: fire one event of each type (of_filled_out, on_payment, on_payment_missed, on_rebill_missed) — we confirm each landed end-to-end.
Marketplace listing goes up.

Then we're live: any vendor can enable ISFY in two clicks, and every event becomes a callable lead in our dial queue within seconds.