Payments & merchant services · Anonymous delivery

From payment terminal to merchant report

The ecosystem connected software running alongside payment terminals with data exchange, transaction imports, storage and a merchant portal. We worked on the portal at the points where file format, amount precision, time zone or aggregation rules could change how the same transaction appeared.

Verified delivery outcome

Explicit rules for imports, amounts and time; controlled acquirer transaction matching; improved filtering and exports; and contextual error monitoring in a modernised portal.

System view

The merchant saw a report. The system had to preserve the path of every transaction.

Before a transaction appeared in the portal, it crossed the device, connections and exchange formats, the import layer, the data model and reporting queries.

Illustrative merchant-payments ecosystem showing a fictional transaction moving from a terminal through data exchange and import to a merchant portal — Original reconstruction based on the delivered scope. The interface, terminal, merchant and data are fictional.

Context

The portal sat inside a wider payments chain

Terminal-side software connected different communication channels and providers. The portal received transaction data, reconciled it with acquirer data, and gave merchants filtering, reporting and export tools.

Client context: A Danish merchant-services ecosystem covering payment terminals, transaction-data exchange and a merchant portal.
CODEVENOM role: Subcontracted delivery within a multi-party supply chain. We directly developed the portal and its data boundaries; the terminal application is shown only as architectural context.

Problem

The meaning of a transaction was spread across several layers

Amount, time, identifier and classification had to remain consistent across different input formats, database rules and ways of presenting data in the portal.

CSV format and delimiter handling affected whether a record was read correctly.
Amount precision depended on database types and the way incoming values were normalised.
Time zone and day boundaries affected transaction filtering, aggregation and display.
RRN matching, operation categories and acquirer data had to stay consistent across lists and exports.

Illustrative risk map showing a transaction amount, time and identifier crossing a terminal, exchange file, import, database and report — The diagram represents a class of problem verified in delivery. Values, formats and names are fictional.

Scope

The work covered the points where data changed format or meaning

We focused on the portal: from receiving a record, through its model and queries, to the view and file delivered to the user.

Transaction imports, CSV parsing, headers and compatibility with current libraries
Amount precision, time zones, dates and data serialisation
Acquirer transaction matching, filtering, aggregation and pagination
Exports, error monitoring, and modernisation of the application and deployment process

Approach

Trace the transaction before changing the report

We tied each change to the path of a specific record: where it came from, how it was normalised, what it was matched with and what the merchant ultimately saw.

01
Identify the source, identifier and input format of the record.
02
Normalise amount and time at a controlled import boundary.
03
Preserve precision and explicit date rules in the model and database.
04
Verify the same record in matching, filters, aggregation and export.

Five-stage flow from transaction source through format, amount and time normalisation, and matching to a merchant report — Working method: source → format → amount and time → matching → report.

Delivered changes

The portal gained explicit control points for each transaction

Instead of treating a reporting error as a problem on one screen, the changes addressed the successive boundaries crossed by values and identifiers.

Updated CSV handling, header mapping and definitions for operations, schemas and acquirers
Decimal types for financial values with an explicit fallback for number normalisation
Controlled time-zone rules across imports, filters and response serialisation
RRN matching in limited batches, multi-format exports and monitoring through Sentry

Result

The portal gained clearer control over transaction data

The delivered work moved critical import, amount, time and matching rules into explicit portal mechanisms. The available evidence supports these system changes; it does not include measured transaction volume, reconciliation time, uptime or settlement accuracy.

Illustrative comparison of scattered transaction rules with a controlled model for imports, amounts, time, matching and reporting — Results are shown at system level without unsupported financial or operational metrics.

Related service

When a B2B portal shows the result of a process running across several systems

We design and develop portals and dashboards that preserve the meaning of data from source to report and give operations teams clear points of control.

Explore B2B portals & dashboards

Start with one transaction

Do different reports show different figures or statuses?

Show us the transaction source, the import path and the report merchants use. We will trace where the amount, time or identifier starts to be interpreted differently.

Start a project