Change Notification

When there is a change or update in a payment or transaction from the Payment Service Provider (PSP), the Integrator must inform Billwerk+Transform of this update. The platform employs a webhook mechanism to handle such notifications as part of its third-party integration strategy.

📘

It is crucial for the Integrator to first process the payment notification from the PSP thoroughly before notifying Billwerk+Transform. This ensures that the data sent to Billwerk is accurate and reflects the latest state of the transaction.

The principal scheme of the notification flow is illustrated below.

Notification Flow

  • Payment Notification from PSP: Once the PSP sends a notification about payment, the Integrator processes this notification by updating the stored data associated with the payment (Preauth, Payment, Refund).
  • Sending Webhook to Billwerk: After processing the notification, the Integrator sends a corresponding webhook to Billwerk. This webhook includes:
    • Transaction Type: Specifies whether the transaction is a Preauth, Payment, or Refund.
    • Billwerk Identifier: The unique identifier for the transaction, as stored by the Integrator.

Billwerk's Role

  • Fetching Transaction Data: Billwerk uses the information from the webhook to fetch the updated transaction data from its endpoint.
  • Comparison of Transaction State: This fetched data allows Billwerk to compare the transaction state stored on its side, ensuring all records are up-to-date.

📘

Billwerk+ Transform relies on the Integrator to aggregate webhooks from the PSP. In scenarios where multiple changes occur simultaneously, the Integrator is expected to notify the platform only of the most recent change, ensuring that Billwerk+ Transform receives timely and accurate updates.

Webhook Types for Billwerk+ Transform

The following table provides a comprehensive overview of the webhook types used in Billwerk+ Transform. Each type corresponds to a specific event that triggers the webhook.

CodeDescription
1Notification related to a preauthorization event.
2Notification related to a payment transaction.
3Notification related to a refund transaction.
4Notification related to an agreement event, such as creation, amendment, or termination

Example 1: Payment Notification Webhook

{
  "TransactionId": "tx123456",
  "Type": 2  // Corresponds to Payment
}

Example 2: Agreement Update Webhook

{
  "AgreementId": "tx123456",
  "Type": 4  // Corresponds to Agreement
}