WEBHOOK SUBSCRIPTIONS ARE LIMITED TO 5 PER PJMID. But a single Webhook can simultaneous track multiple requestI IDs.

For more information on PayJunction account structures, see the PayJunction Account Structures guide.

Available Webhooks

Webhooks can be subscribed to via the PayJunction REST API. The following webhooks are all currently available:

• SMARTTERMINAL_REQUEST
• TRANSACTION
• TRANSACTION_SIGNATURE

Webhooks, like all parts of the API, are tied to the PJMID for an account in PayJunction. If a merchant processes through two different PJMIDs your service will have to subscribe to webhook events for both accounts to receive all data. Multiple webhook subscriptions can be posted to PayJunction for each account and type of webhook if needed.

SMARTTERMINAL_REQUEST

This webhook is triggered any time a transaction changes state as it is processed via the Smart Terminal, regardless of whether the transaction was initiated via the PayJunction REST API or another service, such as our Virtual Terminal web interface.

For examples and details please see the SMARTTERMINAL_REQUEST Webhook page.

TRANSACTION

This webhook is triggered any time that a transaction is processed through a PayJunction account, regardless of which PayJunction service the transaction was initiated through, such as our Virtual Terminal, Smart Terminal, or Hosted Payments secure hosted checkout service.

Example TRANSACTION Webhook Payload

{
  "id" : "2bc89720-2c25-4765-93cf-b695bd3801da",
  "created" : "2020-03-05T17:52:10.557Z",
  "type" : "TRANSACTION",
  "data" : {
    "transactionId" : 10157
  }
} 

For more details please see the TRANSACTION Webhook page.

TRANSACTION_SIGNATURE

This webhook is triggered any time that a transaction is signed on a PayJunction account. As with the SMARTTERMINAL_REQUEST webhook, this is sent regardless of whether the transaction was initiated via the PayJunction REST API or another service, such as our Virtual Terminal web interface.

Example TRANSACTION_SIGNATURE Webhook Payload

{ "id": "a7b7f967-d519-4b4c-a5b8-e97347966993", "created": "2016-12-05T18:18:58.674Z", "type": "TRANSACTION_SIGNATURE", "data": { "transactionId": "137" } }

Important Considerations

WEBHOOK SUBSCRIPTIONS ARE LIMITED TO 5 PER PJMID. But a single Webhook can simultaneous track multiple requestI IDs.
For more information on PayJunction account structures, see the PayJunction Account Structures guide.

WEBHOOKS ARE SOURCE AGNOSTIC

As mentioned previously, webhooks are emitted regardless of the source that initiated the transaction or event. If you are only interested in processing webhooks for transactions initiated by your software or service, you will need to keep track of the requestPaymentId value. You'll then match this value with the same parameter returned in the SMARTTERMINAL_REQUEST data payload and drop any requests with unrecognized requestPaymentId values.

TRANSACTION and TRANSACTION_SIGNATURE webhooks can be referenced by the transactionId and Pj-Merchant and Pj-Account Header values. See Webhook HTTP Pj-Headers

RESPOND TO A WEBHOOK WITH A SUCCESSFUL HTTP STATUS CODE

PayJunction expects to be able to connect to integrators within 5 seconds, and for integrators to respond within 15 seconds of receiving a webhook event. If your service takes longer to complete, the connection will be terminated and the event will be requeued and sent at a later date.

Failed webhook retry delay:

• Attempts 2-5: 30 second delay
• Attempts 6-10: 5 minute delay
• Attempt > 10: 1 hour delay*

*After 3 days we will no longer attempt to send the webhook event and it will be deleted.

To prevent a flood of redundant webhook data, make sure your listening service responds with a 2xx HTTP status code to tell PayJunction the webhook was consumed successfully.

WEBHOOKS MAY BE RECEIVED MORE THAN ONCE

If the response from the listening service is not received in a timely manner, you may receive the same webhook notice more than once. It is important to consider this when building your listening service and databases.

Our webhook infrastructure guarantees "at least once delivery" which optimizes fault-tolerance, and scalability to deal with all kinds of failures throughout the Internet and in our client's networks but imposes a small burden on our clients to be ready to accept duplicate webhooks from time to time even if they respond with HTTP 200.