Webhooks

Set up an endpoint in Repejo

An endpoint is the HTTPS URL in your system that receives the events. Log in to Repejo as an administrator and do these steps:

1. Click Settings (Inställningar) in the top menu.
2. Click Webhooks in the left menu.
3. Click Add webhook.
4. In URL, type the HTTPS URL of your endpoint.
5. In Description, type a name that tells what system receives the events.
6. Keep Send failure alerts selected. Repejo then sends an email when deliveries to the endpoint fail, at most once a day. The email goes to the users who have Receive error alerts (Få felaviseringar) turned on in their user settings.
7. Under Subscribed Events, select the events that your system needs.
8. Click Create.
9. In the list of endpoints, click Show next to Secret.
10. Copy the secret key to your endpoint. Your endpoint needs it to make sure that the signature is correct.

Each endpoint gets its own secret key. If you have one endpoint in the test environment and one in production, they have different keys.

See the deliveries

1. Click Settings, then Webhooks.
2. Click Deliveries (Leveranser) in the left menu. Each row shows the event, the status and the HTTP response of your endpoint.
3. To see the JSON that Repejo sent, click View payload.
4. To send an event again, for example after you fixed your endpoint, click Resend.

Embedded relations

• Subscription events always embed the related payer as a nested object (the same fields the payer payload carries), in addition to payer_id. The field is null when no payer is linked or the payer can no longer be loaded (for example, it was deleted).
• Subscription events embed the related payment_method as a nested object with type-specific fields (see PaymentMethod). The field is null when no payment method is linked.
• Transaction and receivable events always embed the linked payer as a nested object (same fields as the subscription payer). The field is null when no payer is linked or the payer can no longer be loaded (for example, it was deleted).
• Transaction events carry subscription_id, the subscription of the transaction's receivable, or null when the receivable has none. A one-time gift can carry one too, so read type ("recurring" or "onetime") to tell a monthly charge from a one-time payment.
• Each month of a recurring gift sends receivable.created (unpaid, or rejected when no Autogiro payment order stands behind it) and, once paid, receivable.updated. A card, Apple Pay, Google Pay or Swish charge sends transaction.created with status pending when it starts and transaction.updated when the outcome is known. An Autogiro charge sends one transaction.created with the outcome from the bank's file. Events can reach you out of order, because a failed delivery is retried later. A transaction never goes back to pending, so ignore a pending event for a transaction you already have with another status.
• Receivable events always include external_transaction_id and paid_at. external_transaction_id holds the external id when the receivable has a successful transaction with one — Adyen's pspReference for an Adyen payment — and is null otherwise. paid_at is the ISO 8601 UTC timestamp of the payment (exact for Swish, card, Apple Pay, Google Pay and invoice; 12:00 Europe/Stockholm on the paid date for Autogiro, Bankgiro, Stripe subscriptions and offline payments) and null for unpaid receivables. See the Receivable payload for details.
• On an Adyen recurring gift the donor pays the first period in the checkout, so the first period is already paid when subscription.created arrives. The signing sends a paid receivable.created and a transaction.created dated the signing day. If your organisation charges later periods itself (collected_by is "organisation"), your first charge is for the second period. Do not charge the first period again.
• payment_session.succeeded embeds the resulting subscription, the signed payment_method object (same type-specific fields as the subscription payment method) and the payer, plus payment_channel, collected_by and the deprecated payment_method_type, which replace the scalar preselect payment_method. For a one-time session (no subscription) all of these except the payer are null; the payer is always present.
• data.request_type echoes what the session was created for, on all four payment_session.* events: subscription or payment_method. A payment_method session sets up an Autogiro mandate alone, so its subscription, amount and currency are null while payment_method and payer are populated, and its documents carry only the signature XML.
• payment_session.finalized has the same shape as succeeded plus a documents object. It is sent for every succeeded session once post-processing has finished (for a one-time payment, straight after succeeded), whether or not any document exists.
• Subscription events and payment_session.finalized carry a documents object with mandate_pdf_masked_url, mandate_pdf_unmasked_url and signature_xml_url. Each is an authenticated API url (send your Bearer token) or null when that document does not exist at the time of the event: PDF urls appear once the mandate PDF has been rendered (right after signing for Autogiro and SEPA Direct Debit mandates on a checkout that enables the mandate language, Swedish / German); the XML url exists only for mandates signed with BankID. See Payment Sessions for the endpoints.
• Payer events are sent without extra relations unless something else has been added to the entity before publication.

Headers

Content-Type: application/json
User-Agent: Repejo-Webhooks/1.0
X-Repejo-Delivery-ID: <delivery_id>
X-Repejo-Event-ID: <event_id>
X-Repejo-Event-Type: <event_type>
X-Repejo-Attempt: <attempt>
Repejo-Signature: sha256=<hex>

Tutorial: Autogiro mandates managed outside Repejo

Use this flow when Repejo collects and signs the Autogiro mandate, but your own CRM or backend talks to Bankgirocentralen and charges the donor. For example, Repejo runs the face-to-face or website checkout, and your system sets up the Autogiro payments.