Successful Payments

The Successful Payments report is the core of your reconciliation. It contains every successful payment processed through NjiaPay, plus any PSP-only transactions. Each row can be in one of three states:

• Matched: found in both NjiaPay and the PSP settlement file (exists_in_njia = True, exists_in_psp = True). All columns are populated, including PSP amounts, fees, and break flags.
• Unmatched (NjiaPay only): exists in NjiaPay but no corresponding PSP settlement record was found yet (exists_in_njia = True, exists_in_psp = False). Only the NjiaPay columns are filled; all PSP columns and break flags are empty.
• PSP only: exists in the PSP settlement file but NjiaPay has no record of it (exists_in_njia = False, exists_in_psp = True). This means the payment was made outside of NjiaPay, either via a manual payment link created directly in the PSP dashboard, or from historical transactions that predate your NjiaPay integration. Only PSP columns are filled.

When to Use This Report

• As your primary reconciliation worksheet. Filter to see matched vs. unmatched at a glance
• To review processing fees charged by each PSP on matched transactions
• To calculate your net revenue after fees and currency conversion
• To identify amount breaks, i.e. discrepancies between what NjiaPay recorded and what the PSP settled
• To track which successful payments are still awaiting settlement confirmation

Column Reference

The report has three groups of columns: NjiaPay side (what NjiaPay recorded), PSP side (what the PSP settlement file says), and Break flags (discrepancy indicators).

NjiaPay Columns (populated when exists_in_njia = True)

PSP Columns (populated only when matched)

These columns are filled when exists_in_psp = True. When the transaction is unmatched, they are all empty.

Reconciliation & Break Columns

Example Data

Below are complete example rows exactly as they appear in the CSV. The table is wide -- scroll right to see all columns.

Matched transaction (Adyen, GBP, no currency conversion)

This row is matched (exists_in_njia = True, exists_in_psp = True). Both sides agree on amount and currency (no breaks). break_created_month = True is normal -- the PSP settlement batch date (September) differs from the NjiaPay transaction date (November) because Adyen settles in batches that may lag behind.

After Adyen's fee of GBP 0.84 (2.1% effective rate), the net payout is GBP 39.16. No currency conversion since both sides are in GBP (psp_exchange_rate = 1.0).

Matched transaction (Adyen, NZD with currency conversion to EUR)

The customer paid NZD 30.0 but Adyen converted it to EUR for settlement. The exchange rate 0.484 means: (30.0 * 0.484) - 0.51 = 14.01, rounded to 14.0. The psp_net_currency is EUR (not NZD), which is the currency that actually lands in the merchant's bank account.

Unmatched transaction (NjiaPay only, awaiting PSP settlement)

All PSP columns are empty because no matching PSP settlement record was found. Either the settlement file hasn't been uploaded yet, or the PSP doesn't have settlement integration.

PSP-only transaction (exists_in_njia = False)

All NjiaPay columns are empty. This transaction was processed directly through the PSP (e.g. a manual payment link created in the Adyen dashboard), or it predates the merchant's NjiaPay integration.

Key observations

• Unmatched rows (exists_in_psp = False): NjiaPay recorded the transaction but no PSP settlement was found. StartButton and Precium rows are always unmatched because those PSPs don't have settlement integration yet. Adyen/PayPal rows are usually waiting for the settlement file upload.
• Matched rows (both True): Fully reconciled. Check break_gross_amount and break_currency for discrepancies.
• PSP-only rows (exists_in_njia = False): The PSP settlement has a transaction that NjiaPay doesn't know about. This means it was made outside NjiaPay (manual payment link, or pre-NjiaPay history).

How to Read This Report

Quickly Separate Matched from Unmatched

In your spreadsheet, filter or sort by the exists_in_psp column:

• True rows are fully reconciled. Both sides agree (check break flags for exceptions)
• False rows are still awaiting PSP settlement confirmation

A quick summary formula:

Matched count:    =COUNTIF(report[exists_in_psp], "True")
Unmatched count:  =COUNTIF(report[exists_in_psp], "False")
Match rate:       =COUNTIF(report[exists_in_psp], "True") / COUNTA(report[exists_in_psp])

Understanding the Fee Breakdown (Matched Rows Only)

For each matched transaction, you can calculate the effective fee rate:

Fee Rate = psp_total_costs / psp_gross_amount * 100

For example, a transaction with psp_gross_amount = 40.0 GBP and psp_total_costs = 0.84 GBP has an effective fee rate of 2.1%.

Understanding Currency Conversions

When the PSP converts currencies (e.g. NZD to EUR for settlement), you will see:

• njia_currency = NZD and psp_gross_currency = NZD (original currency matches)
• psp_exchange_rate = 0.484 (the NZD-to-EUR rate applied)
• psp_net_currency = EUR (the settlement currency after conversion)
• psp_net_amount = 14.0 (what lands in your EUR account)

The formula is: psp_net_amount = (psp_gross_amount * psp_exchange_rate) - psp_total_costs

Understanding Break Flags (Matched Rows Only)

Break flags only appear on matched rows. break_created_month = True is normal and expected. It means the NjiaPay transaction was recorded in a different month than the PSP settlement batch. PSPs typically settle in batches that may lag behind the actual transaction date by days or weeks.

When to investigate:

• break_gross_amount = True: the PSP settled a different amount than NjiaPay recorded. Check for partial refunds, chargebacks, or currency rounding.
• break_currency = True: the currencies don't match. This can happen with certain PSP configurations.

Why Are Some Successful Payments Unmatched?

Common reasons a successful payment may not yet have a PSP settlement match:

Why Does a Row Have exists_in_njia = False?

A row with exists_in_njia = False means the PSP settlement file contains a transaction that NjiaPay has no record of. Common causes:

• Manual payment links created directly in the PSP dashboard (e.g. Adyen, Paystack, or PayPal payment links). Someone on your team may have created a one-off payment link in the PSP's own UI, bypassing NjiaPay.
• Historical transactions from before you started using NjiaPay. If the uploaded PSP settlement file covers a period that predates your NjiaPay integration, those older transactions will appear here.
• PSP reference mismatch (rare): the PSP recorded a different reference than expected, preventing the match.

These rows will only have PSP columns filled. The NjiaPay columns (njia_merchant_ref_id, njia_currency, njia_amount, etc.) will all be empty.

Review these transactions to determine whether they are expected. If they are not, contact your PSP to investigate.

Tips for Working with This Report

Calculate Net Revenue by Currency (Matched Only)

=SUMIFS(report[psp_net_amount], report[psp_net_currency], "USD", report[exists_in_psp], "True")

Calculate Unmatched Exposure by Currency

=SUMIFS(report[njia_amount], report[njia_currency], "USD", report[exists_in_psp], "False")

Calculate Total Fees by PSP

=SUMIFS(report[psp_total_costs], report[psp_type], "AdyenGlobal", report[psp_cost_currency], "USD")

Find Transactions with Amount Breaks

Filter to exists_in_psp = True AND break_gross_amount = True to see all discrepancies at a glance.

Related Reports