Transaction Query Endpoint

Retrieve detailed information about a transaction using its unique reference number.

This endpoint allows merchants to query and fetch complete details of a transaction, including tickets, metadata, and pricing breakdowns. Use this endpoint to verify transaction status, retrieve booking details for customer support, or reconcile payments.

CRITICAL - How Our Transaction System Works

Our system is designed to only create transactions when they are successful. This means:

  • ✅ Transactions are ONLY created when payment succeeds AND booking is confirmed

  • ✅ Your wallet is ONLY debited when the transaction is successful

  • ❌ If a purchase attempt fails (experience has passed, bus seats are full, room unavailable), we return a failed response

  • ❌ Failed attempts DO NOT debit your wallet

  • ❌ Failed attempts DO NOT create transaction records

Result: If a transaction exists in our system, it is guaranteed to be successful. There are no failed or pending transactions in our database.


Query Transaction Details

GET /api/v1/merpi/transaction/{reference}

Fetch detailed information about a specific transaction using its reference number.

Path Parameters

Parameter
Type
Required
Description

reference

string

Yes

Unique transaction reference number. Format varies by transaction type:<br/>- Experience: EX + numbers (e.g., EX142799733)<br/>- Transportation: TR + numbers (e.g., TR196608948)<br/>- Hospitality: HTL + numbers (e.g., HTL103088777)

Query Transaction Details by Reference

get

Retrieves detailed information about a transaction using its unique reference number.

Important: Our system only creates transactions when they are successful. If a purchase attempt fails (e.g., experience has passed, bus seats are full, room unavailable), we return a failed response and DO NOT debit your wallet or create a transaction record.

This endpoint returns comprehensive transaction details including tickets, metadata, and pricing breakdowns. The response structure varies based on the transaction type (Experience, Transportation, or Hospitality).

Path parameters
referencestringRequired

Unique transaction reference number. Format varies by transaction type:

  • Experience: EX + numbers (e.g., EX142799733)
  • Transportation: TR + numbers (e.g., TR196608948)
  • Hospitality: HTL + numbers (e.g., HTL103088777)
Example: EX142799733
Responses
chevron-right
200

Transaction found successfully.

application/json
successbooleanOptionalExample: true
statusintegerOptionalExample: 200
messagestringOptionalExample: Transaction Found
get
/v1/merpi/transaction/{reference}

Responses

Status
Description

200

Successfully retrieved transaction details

400

Bad Request - Invalid or missing reference parameter

404

Not Found - Transaction doesn't exist

500

Internal Server Error


Response Format

Root Response Object

Field
Type
Description

success

boolean

Indicates whether the request was successful.

status

integer

HTTP status code (200 for successful requests).

message

string

Human-readable description of the response.

data

object

Transaction details object.

Data Object (Common Fields)

All transaction types share these common fields:

Field
Type
Description

reference

string

Unique transaction reference.

status

string

Transaction status. Always "success" since only successful transactions are stored.

transaction_type

string

Type of transaction: "Experience", "Transportation", or "Hospitality".

amount

string

Total transaction amount (formatted with commas).

charges

string

Convenience fee charged.

business_commission

string

Commission paid to merchant.

transaction_id

string

Internal transaction ID (prefixed with TEX, TTR, or THO).

customer_email

string

Email of the customer who made the purchase.

purchased_at

string

Date and time of purchase (format: DD-MM-YYYY HH:MM AM/PM).

ticket

array

Ticket information. Structure varies by transaction type.

metadata

object

Additional transaction details. Structure varies by transaction type.


Response Differences by Transaction Type

1. Experience Transaction (Non-Cinema)

Ticket Structure (Experience - Non-Cinema):

  • id - Ticket type ID

  • price - Base ticket price

  • count - Number of tickets purchased

Metadata Structure:

  • experience - Complete experience details

  • tickets - Array of ticket type details with price breakdowns


2. Experience Transaction (Cinema)

Additional Cinema Fields:

  • attendance_date - Date the customer will attend the movie

  • time - Specific showtime details (start and end time)


3. Transportation Transaction (Timed Schedule)

Ticket Structure (Transportation - Timed):

  • price - Ticket price per seat

  • seat_id - Specific seat ID assigned to the passenger

Metadata Structure:

  • departure_date - Date and time of departure

  • schedule_bus - Complete schedule and bus details

  • time.departure - The exact time the bus departs on the departure date (for timed schedules)


4. Transportation Transaction (Random Schedule)

Ticket Structure (Transportation - Random):

  • id - null for random schedules

  • price - Total ticket price

  • count - Number of tickets

  • seat_count - Number of seats (0 for random since no specific seat assignment)

  • total_amount - Total amount for all tickets

Key Difference: Random schedules don't assign specific seats (seat_id), so the ticket structure is different.


5. Hospitality Transaction (Hotel Booking)

Ticket Structure (Hospitality):

  • price - Room price

  • room_id - Specific room ID

Metadata Structure:

  • checkin_date - Check-in date (YYYY-MM-DD)

  • checkout_date - Check-out date (YYYY-MM-DD)

  • number_of_nights - Length of stay

  • number_of_rooms - Number of rooms booked

  • number_of_guests - Total number of guests

  • hotel - Complete hotel details

  • room - Room details

  • booking_number - Unique booking confirmation number

Additional Fields:

  • booking_number - Also available at root level for easy access

  • price_breakdown - Also available at root level


Request Examples

Using cURL

Using JavaScript (Fetch)

Using Python (Requests)

Using PHP


Understanding Transaction Types

Identifying Transaction Type

You can determine the transaction type in two ways:

  1. From the reference prefix:

    • EX + numbers = Experience

    • TR + numbers = Transportation

    • HTL + numbers = Hospitality

  2. From the transaction_type field in the response:

    • "Experience"

    • "Transportation"

    • "Hospitality"

Handling Different Response Structures


Common Use Cases

1. Customer Support - Transaction Lookup

2. Payment Reconciliation

3. Generating Booking Confirmation

4. Verifying Transaction Before Refund


Key Differences Between Transaction Types

Feature
Experience
Transportation (Timed)
Transportation (Random)
Hospitality

Reference Prefix

EX

TR

TR

HTL

Ticket Structure

{id, price, count}

{price, seat_id}

{id, price, count, seat_count, total_amount}

{price, room_id}

Seat Assignment

No

Yes (specific seats)

No (general admission)

Room assignment

Date Field

start_date, end_date

departure_date

departure_date

checkin_date, checkout_date

Confirmation Number

No

No

No

Yes (booking_number)

Cinema Variation

Yes (cinema: true/false)

No

No

No

Schedule Type

N/A

timed

random

N/A


Error Handling

400 - Bad Request

Occurs when the reference parameter is missing or invalid:

Common causes:

  • Missing reference parameter

  • Invalid reference format

  • Reference contains invalid characters

404 - Not Found

Occurs when no transaction exists with the provided reference:

Response fields:

  • message - Includes the reference that was searched

  • errors - Error description

Common causes:

  • Transaction reference doesn't exist

  • Typo in reference number

  • Attempting to query a failed transaction (which doesn't exist in our system)

500 - Internal Server Error

Error Handling Example


Important Notes

Why Only Successful Transactions Exist

Our platform follows a strict "success-only" transaction model:

  1. Validation happens BEFORE wallet debit: We check availability (seats, rooms, event status) before attempting payment

  2. Atomic operations: Payment and booking confirmation happen together

  3. No partial states: Either the entire transaction succeeds, or nothing is recorded

  4. Wallet safety: Your wallet is never debited unless the booking is confirmed

This means:

  • ✅ If you can query a transaction, it was successful

  • ✅ If payment was debited, the booking was confirmed

  • ❌ Failed attempts don't appear in transaction queries

  • ❌ No "pending" or "processing" states exist

Transaction Reference Patterns

Experience transactions:

  • Format: EX + 9 digits

  • Example: EX142799733

Transportation transactions:

  • Format: TR + 9 digits

  • Example: TR196608948

Hospitality transactions:

  • Format: HTL + 9 digits

  • Example: HTL103088777

Date Format Handling

The API returns dates in different formats depending on the field:

  • purchased_at: DD-MM-YYYY HH:MM AM/PM (e.g., "07-08-2024 12:59 PM")

  • departure_date: Day, DD Mon YYYY HH:MM AM/PM (e.g., "Wed, 09 Apr 2025 08:21 PM")

  • checkin_date / checkout_date: YYYY-MM-DD (e.g., "2026-03-03")

  • start_date / end_date: ISO 8601 (e.g., "2023-03-05T17:30:00")

Always parse dates appropriately based on the field you're working with.


Next Steps

After querying a transaction, you can:

  • Generate confirmation emails - Send booking details to customers

  • Print tickets/vouchers - Use transaction details to generate printable tickets

  • Track bookings - Build a dashboard to monitor all transactions

  • Process refunds - Verify transaction details before issuing refunds

  • Customer support - Quickly look up transaction details for support inquiries

  • Reconciliation - Match transactions with payment records


Last updated