Skip to content

Troubleshooting

Diagnose before you guess, then jump to the symptom you are actually seeing.

Most integration problems look like a mystery for about two minutes, and then turn out to be one of a dozen things. This section is organised the way you arrive: by what you are seeing, not by what it is called.

Before you open any page below, collect three things. With them, almost every question answers itself, and without them support cannot help you either.

WhatWhere it isWhy it settles the question
The payment idtransaction.id on the create response, trx_…Names the object on Wajub's side
The request idX-Request-Id on any responseNames the exact call in Wajub's logs
The environmentThe key prefix, pk_test. or pk.Sandbox and live are different databases

That last row is the single most common false alarm. A sandbox object is invisible to a live key and the other way round, and the id says which: everything created in sandbox carries test_ after its prefix, as in trx_test_CSUGajfv9xh0XQ5wu2lx.

Start in Konsole

Konsole shows the request you actually sent, the response Wajub actually returned, which provider was picked, and whether the webhook was delivered. Reading it takes less time than reasoning about what your code should have done.

You want to knowOpen
What my code sent and got backAPI Logs
Why this provider was chosenRouting Log
Whether my endpoint answeredWebhook Tester
What is happening right nowEvent Stream

Go to your symptom

When it is not you

Platform incidents, degradations and maintenance windows are published on status.wajub.com. Check it before you spend an hour on a failure rate that started at the same minute for everyone.

When none of this helps

Write to support@wajub.com with the three things from the table at the top, plus what you expected to happen. A request id turns a conversation that takes two days into one that takes ten minutes, because it points at the exact call rather than at a description of it.

What did you think of this content?