> ## Documentation Index
> Fetch the complete documentation index at: https://waffo.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Transaction & Refund Field Reference

> What each field on a Portal payment or refund record actually means: the two merchant order IDs on a refund, Initiation Type (CIT/MIT) and why it is usually empty, the card details and how the card number is masked, why an amount reads as a dash, and why the Refund button is missing or greyed out.

This page is a field-by-field reference for a single payment or refund record in the Portal —
what a column means, and why it is empty when you expected a value. Refund *rules* (how many, how
much, cross-currency, returned fees) are in [Refund FAQ](/docs/en/support/refund-faq); dashboard metrics
in [Portal Dashboards & Analytics](/docs/en/support/portal-analytics-faq); collecting exported files in
[Exports & Report Downloads](/docs/en/support/export-center-faq).

## Which identifiers does a payment carry, and which should I quote?

Four, and they are not interchangeable:

| Column | Whose identifier | Use it for |
| - | - | - |
| `Order Id` | Waffo's | Quoting a transaction to Waffo support — this is the one to send |
| `Merchant Order Id` | Yours | Matching back to your own order record |
| `Payment Request Id` | The request | Tracing the specific attempt that created the order |
| `Merchant User Id` | Yours | The customer reference you passed at order creation |

When you raise a ticket, lead with `Order Id`. Your own order ID is useful as a cross-check but is
not unique across the platform, so on its own it is slower to trace.

Refunds carry their own set — see below.

## Which timestamps does a payment carry, and why are there three?

| Column | What it marks |
| - | - |
| `Created Datetime` | When the order was created |
| `Payment Date` | The date the payment is attributed to |
| `Payment Time` | The time of the payment itself |

They separate deliberately: an order created just before midnight and paid just after it has a
creation timestamp on one day and a payment date on the next. Reconcile against `Payment Date` when
you are matching a payout, and against `Created Datetime` when you are investigating order volume
or a limit rejection — the daily transaction limit counts from creation, as described in
[Payin Agreements & Transaction Limits](/docs/en/support/payin-agreements-and-limits-faq).

An unset timestamp renders as `-`, so an unpaid order shows a creation time and dashes for the other
two.

## A refund shows two merchant order IDs. Which is which?

They are different objects, and confusing them is the most common reconciliation error:

| Column | Belongs to | Contains |
| - | - | - |
| `Merchant Order Id` | The **refund** | The order ID *you* assigned to the refund request |
| `Merchant Original Order ID` | The **original payment** | The order ID you assigned to the payment being refunded |

So to trace a refund back to the sale, use `Merchant Original Order ID`. To trace your own refund
instruction, use `Merchant Order Id`.

`Merchant Original Order ID` appears on the refund list, on the refund detail's merchant
information block, and in refund exports. Where the value is absent the Portal shows `-`.

The Waffo-side identifiers sit alongside them: the refund's own acquiring order ID, the refund
request ID, and — where the refund came from a batch — a `Refund Batch ID`, which is `-` for a
single refund.

## Can I search refunds by the original payment's order ID?

Yes. `merchantOriginalOrderId` is one of the fields in the refund list's combined search selector,
and it matches **exactly** — not as a prefix or a substring. Paste the full original order ID.

If it returns nothing, check that you are searching the original *payment's* ID and not the refund's
own, and that the value has no trailing whitespace.

## Why is the Refund button missing or greyed out?

There are three states, and they mean different things:

| State | What it tells you |
| - | - |
| Button **absent** | This order can never be refunded from the Portal — its status is not a successful payment, or the agreement does not permit refunds at all |
| Button **greyed out** | Refunds are possible for this kind of order, but this particular order does not currently qualify |
| Button **active** | You can refund |

When the button is greyed out, one of these five conditions has failed:

| Condition | Why it blocks |
| - | - |
| Refund shape still available | The agreement may allow only one refund, or only a full one — if that has been used, no further refund fits |
| Inside the refund period | Refunds are only accepted within the agreement's refund window, counted from order creation and inclusive of the first and last day |
| No dispute hold on the order | An order under dispute is held and cannot be refunded from the Portal |
| Under the maximum refund count | An order has a cap on how many refund records it may carry, counting both successful and in-progress ones |
| Remaining refundable amount above zero | Fully refunded — or with a full refund still in progress — leaves nothing to refund |

Note that in-progress refunds count in the last two. A refund you submitted seconds ago already
consumes both a slot and its amount, which is why the button can grey out before anything has
settled.

The refund panel and the order detail both show `Remaining Refundable Amount` so you can see the
third figure directly. Which payment methods support refunds at all is on your
[Payin agreement page](/docs/en/support/payin-agreements-and-limits-faq).

Users without the refund permission never see the button regardless of the above — see
[Merchant Portal Operations](/docs/en/support/portal-operations-faq).

## What is the Initiation Type column?

`Initiation Type` classifies who triggered a card transaction:

| Value | Meaning |
| - | - |
| `CIT` | Cardholder-initiated — the customer was present and acting, as on a first payment or a manual re-purchase |
| `MIT` | Merchant-initiated — you triggered it against a stored authorisation, as with a subscription renewal |

It is a **per-transaction** attribute, so it lives on the payment list and not on aggregate views.

## Why is Initiation Type always showing a dash?

Because the value is only populated when you **filter by it**. This is by design, not a gap in your
data:

| What you do | What the column shows |
| - | - |
| Open the payment list normally | `-` on every row |
| Filter `Initiation Type` = `CIT` | `CIT` on the returned rows |
| Filter `Initiation Type` = `MIT` | `MIT` on the returned rows |

So the column is a **confirmation of your filter**, not a browsable attribute. To see the split, run
the query twice — once for each value — rather than scanning an unfiltered list.

The column is also only present for accounts contracted for subscriptions, since that is where the
distinction carries weight. If it is not in your list at all, that is why.

## Which card details does a payment record show?

On the payment detail's payment-information block, where the payment method is a card:

| Field | Notes |
| - | - |
| `Cardholder name` | As supplied at payment |
| `Card number` | Masked, with the card scheme's logo |
| `Card expiry date` | As supplied at payment |
| `Issuing country` | The card's issuing country |
| `Issuing bank` | The card's issuer |
| `Order Failure Code` | Present on failed orders only |
| `Order Failure Description` | Present on failed orders only |

Every one of these rows is **omitted when it has no value** — the block does not show empty labels.
So a missing `Issuing bank` row means that datum was not available for that transaction, not that
the field was removed. Non-card payment methods show none of the card rows.

The values are those recorded against that transaction. They are not refreshed afterwards, so two
transactions on the same card taken at different times can legitimately differ.

`Cardholder name` is personal data about your customer. Treat it accordingly in anything you export
or store.

## How is the card number masked?

**First 6 digits, then asterisks, then the last 4** — for example a 16-digit number shows six
digits, six asterisks and four digits. Shorter values degrade safely: a value of 6 to 9 characters
shows the first 6 and asterisks for the rest; anything shorter is shown unchanged.

The full number is never available in the Portal or in exports, and there is no setting that
reveals it. If you need to match a card across transactions, use the masked value together with the
expiry date and scheme rather than expecting a full number.

## Why does an amount show as a dash?

The Portal renders an amount only when it has **both** a number and a currency. If either is
missing, the cell shows `-`.

This is worth knowing because `-` therefore does not mean zero. A genuine zero renders as a
formatted `0.00` with its currency code; a dash means the pair was not available.

## How are amounts and currencies formatted?

| Rule | Behaviour |
| - | - |
| Order | The **amount first, then the currency code** — `1,234.56 USD`, not `USD 1,234.56` |
| Grouping | Thousands separators and decimals in the `en-US` convention, regardless of the interface language you selected |
| Symbol | Currency **symbols are stripped**; only the three-letter code is shown |
| Direction | Where a record has a direction, a credit is prefixed `+` and a debit prefixed `-` and shown in red |

If you are parsing exported figures, parse against the code, not a symbol, and do not assume the
separator convention follows the Portal language setting.

## Why is there no Settlement Status column on the payments list?

There is not one on main. The payments list carries the order's own status, its creation and payment
timestamps, and — where relevant — its subscription ID, but not a settlement state.

Settlement status **is** available on the Disputes list, where it is both a column and a filter.
For payment-level settlement information, work from the settlement reports rather than the
transaction list: see [Settlement reports](/docs/en/support/settlement-reports-faq) and
[Settlement cycle](/docs/en/support/settlement-cycle-faq).

## What are Order Failure Code and Order Failure Description?

They appear only on orders that failed, and they are the two halves of the same answer: a stable
code you can branch on in your own systems, and a human-readable description of it. Use the code
for logic and the description for support conversations.

Common failure causes and what to do about them are collected in
[Errors & troubleshooting](/docs/en/support/errors-troubleshooting-guide) and, for limit rejections
specifically, in [Payin Agreements & Transaction Limits](/docs/en/support/payin-agreements-and-limits-faq).

## Why does a payment record show a subscription ID?

Because the payment was taken under a subscription. The payment list carries the related
subscription ID so a single charge can be traced back to the agreement that produced it; it is `-`
on one-off payments.

Going the other way — from a subscription to its charges — is covered in
[Subscription lifecycle management](/docs/en/support/subscription-lifecycle-management).

## Which fee figures does a payment record show?

The payment detail carries a `Fees` block with the fee charged on that transaction, as an amount
plus its fee currency. Your fee **basis** — percentage, flat, floors and ceilings — is not on the
transaction; it is on your
[Payin agreement page](/docs/en/support/payin-agreements-and-limits-faq).

For how fees behave when a payment is refunded, including partial refunds, see
[Refund FAQ](/docs/en/support/refund-faq).

## The Portal shows a dash where the docs mention a field. Is data missing?

Usually not. The Portal deliberately renders `-` rather than `N/A`, an empty cell, or a zero in
three distinct situations, and telling them apart saves a support ticket:

| Cause | Example |
| - | - |
| The attribute does not apply to this record | `Refund Batch ID` on a single refund; a subscription ID on a one-off payment |
| The attribute only populates under a specific query | `Initiation Type` outside a CIT/MIT filter |
| The value was not available for this transaction | An issuing bank the card data did not carry |

None of the three is recoverable by re-opening the record. Where the second applies, re-run the
query with the relevant filter.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.