Documentation

Getting Started with a Build

Once you know what TruModule needs to do, this page covers what happens next: the practical steps between here and a live, accredited build.

You'll be supported through this by a TruRating Solutions Architect (SA). The process below is what to expect from working with them.

What we need from you

To keep the build on track, have these ready as things progress:

  • Target products, devices, and terminal types you want TruModule to support, so your SA can scope test outlets and accreditation correctly.
  • Languages required: which languages the integration must support, so question sets, rendering, and any on-screen language selection are scoped from the start rather than retrofitted.
  • Trigger points and transaction flows: where in your customer journey TruModule questions should appear.
  • Test environment access: a way for TruRating (or you, under TruRating's guidance) to exercise your build during accreditation.
  • Test hardware or a reference environment: any specific terminals, devices, or environment set-up TruRating needs to test against, and who provides them. Agree this early so it isn't a blocker at accreditation.
  • Merchant ID and Terminal ID conventions: how these are structured and assigned within your platform.
  • Deployment and update process: how a TruModule change reaches live merchants: release cadence, rollout mechanism, and how quickly configuration can be changed or TruRating disabled if needed. This shapes both accreditation and post-go-live change management.
  • Sample requests and responses from your integration once development starts, so message-level issues surface early.
  • UX flows and screenshots of your question and receipt screens, ahead of development, for sign-off.
  • UAT support: someone who can run, or support TruRating in running, the User Acceptance Testing scripts against your real target system.
  • Advance notice of changes to device, POS, payment flow, language, or screen behavior that could affect TruModule, both before and after go-live.

1. Get a development environment

Three things happen before you write any integration code:

  • Partner ID and TransportKey. TruRating creates your partner account and issues a Partner ID (PID) and TransportKey (TKEY) for both sandbox and production, typically once prerequisites are complete. See Security and Reliability (partner sign-in required) for what the TransportKey is used for.
  • Test outlets. TruRating sets up one or more sandbox test outlets with a set of test questions, and agrees Merchant IDs and Terminal IDs with you up front. If your build needs to support multiple languages or several device UIs, it's worth setting up a separate test outlet per variant so development and testing stay simple.
  • Postman collection. On request, TruRating can provide a Postman collection scoped to your target TSI schema version, with worked examples of formatted, unformatted, and hi-fidelity question requests.

The sandbox environment

"Do you have a sandbox?" is one of the first questions most partners ask, so it's worth being clear about what it is and isn't:

  • It's a full TruService sandbox (see TruService Specification), running the same TSI protocol as production. You build and test against it exactly as you would production.
  • It uses test outlets and test question sets that TruRating configures for you, with their own sandbox PID and TransportKey, separate from your production credentials.
  • Ratings and transactions sent to the sandbox are test data. They aren't surfaced in merchant reporting, and it isn't the right place to measure production latency or run load/performance testing; raise either of those with your SA if you need them.

If a build needs to support multiple languages or several device UIs, ask for a separate test outlet per variant so each stays simple to test in isolation.

2. Agree the Technical Scope of Work

As the shape of the integration becomes clear, your SA assembles a Technical Scope of Work (TSOW), the document that defines exactly what your build will do and becomes the baseline the finished build is measured against. See Scoping a Partner Integration for what actually goes into one.

As part of agreeing the TSOW, you'll also agree how accreditation will be completed: whether TruRating provides a test script for you to run yourselves, comes on-site to test in person, or is given a reference environment to test against remotely.

3. Build, with support

TruRating stays involved through the build rather than disappearing until the end:

  • A project plan is shared with you and any other involved third parties.
  • Regular status calls are the norm. Use them to surface blockers early rather than at handover.
  • Share UX and screen flows before you build them, not after. Screen designs, layouts, and customer flows need TruRating sign-off, ideally before development starts. Builds that reach acceptance testing without a prior UX sign-off are typically rejected at that stage, so this step exists specifically to prevent expensive rework, not as a formality.

4. Accreditation

Accreditation exists to protect three things: TruRating's brand, the quality of the anonymous rating data collected, and your own investment in the build actually working correctly in production. It has three parts:

  1. Screen design sign-off: agreed in step 3, ideally before build.
  2. TruModule validation: passing the message-level test scripts TruRating provides, confirming the protocol implementation itself (message content, sequencing, error handling) is correct.
  3. User Acceptance Testing: once TruModule is integrated into the real target system, a further set of test scripts (specific to your system and integration depth) is run end to end, using a test harness you provide.

Every accreditation is scoped to your specific TSOW, so there's no single universal script, but as a generic example the checks typically confirm things like: the MAC header is calculated correctly and rejected requests are handled; Query/Question/Rating/Transaction are sequenced correctly on a stable SessionId; a transaction is still reported when no question was returned; the question renders and clears correctly on timeout, skip, and rating; the correct receipt variant and language are selected; and TruService being slow or unreachable never blocks the host transaction. Your SA maps the exact test cases to what your TSOW commits to.

No build should be treated as production-ready until all three checks pass and the agreed TSOW scope is fully covered. Only then does a build go live with real merchants.

What happens after go-live

Once your build is accredited, TruRating produces the operational documentation that supports it in production, an Implementation & Operations Guide and a Support Guide, and keeps a reference environment so future updates can be re-tested without disrupting live merchants. If your product changes in ways that could affect TruRating (new device, new OS version, new release cadence), flag it to your SA proactively rather than after something breaks.

© 2026 TruRating. All rights reserved.

Patents:
  • GB 2517213 B
  • US 11,836,820 B2
  • US 12,067,563 B2

Patents pending

No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording, or any information storage or retrieval system, without permission in writing from the copyright holder.