Skip to main content
WEBHOOK
Virtual Account application webhooks are available for subscriptions using version V1.5.1, V1.5.2, or V1.6.0. Each event represents the whole application. source_id equals data.application_id, and data contains the latest application details after the event. Events are not sent separately for each receiving method or bank-detail record. Use data.account_id to identify the account that owns the application. When this is a connected account, data.direct_id identifies its main account; when it is the main account, data.direct_id is "0".
virtual.account.create means the application was accepted for processing. It does not mean approval is complete or bank details are ready. Use only bank-detail records whose status is ACTIVE.

When events are sent

The Create response and virtual.account.create webhook can arrive in either order. Do not make one wait for the other. An update can report a skipped or failed method, newly issued bank details, partial completion, final completion, or the closure of an individual bank-detail record. If two methods complete in one change, one final update is sent. If they complete at different times, a partial update is followed by a final update. When an issued bank-detail record closes, use its status immediately. close_reason can still be empty for a closed record.

When events are not sent

No application webhook is sent when:
  • Create returns a synchronous 4xx.
  • Every evaluated receiving method is rejected and no application is created.
  • An identical request is replayed with the same x-idempotency-key.
  • Processing continues but the returned application data has not changed.
If you need the latest data while no event is expected, call Retrieve Virtual Account Application.

Process events safely

  1. Verify x-wk-signature from the raw request body and x-wk-timestamp. See Signature verification.
  2. Deduplicate deliveries by event_id. Retries of the same event reuse this value.
  3. Route the event to the account identified by data.account_id, using data.direct_id to identify its main account when applicable.
  4. Locate the application by data.application_id.
  5. Apply the event only when data.public_version is higher than the version already stored for that application.
  6. Process every entry in data.results[] and identify it by payment_method.
  7. Retrieve the latest application after a delivery gap or suspected out-of-order event.
Always treat a higher public_version as newer, even if the application previously reached FAILED. See Integrate Virtual Accounts with the API for status meanings, error actions, and bank-detail availability rules.

Body

application/json
event_id
string<uuid>
required

A unique identifier for this event.

event_name
enum<string>
required

Top-level event category.

Available options:
VIRTUAL
event_type
enum<string>
required

The specific event type that occurred.

Available options:
virtual.account.create,
virtual.account.update,
virtual.account.closed
source_id
string
required

Virtual Account application ID.

version
string
required

API version number.

Example:

"V1.6.0"

data
object
required

Latest application data after this event. Use application_id and public_version to apply events in order.

Response

200

Return 200 to acknowledge receipt.