Ogloba Processor and API

This reference is for operations and customer-service teams. It describes the Ogloba order lifecycle, the provider fields that prove each step, and the evidence to collect before an escalation or retry.

What Ogloba does

Ogloba is an asynchronous order processor. The application creates and confirms an order, stores the returned order number, and later calls order status until the voucher data is available. The integration does not use a webhook.

Order lifecycle

1. The sale supplies the brand, face value, currency, transaction reference, and country.
2. The interaction selects the first country served by the brand and obtains the brand SKU for the requested face value. Fixed-denomination brands use denomination-specific mappings such as ogloba-sku-10.00.
3. orderCreation sends one item with quantity 1 and delivery type 0 (delivery through the API). The response must contain orderNo.
4. orderConfirm confirms that order with payment type 01 and a payment ID derived from the order number. Its response must also contain orderNo; that value becomes the processor reference.
5. The sale remains asynchronous until retrieval calls orderStatus with that processor reference. The sale is completed only after the status response passes validation and supplies voucher data.

Example API order flow

The following bodies use illustrative values. Merchant credentials, voucher codes, PINs, and live URLs are intentionally omitted.

Create order

The client sends POST orderCreation with the configured country account values and the transaction reference as clientOrderNo:

{
  "merchantId": "<configured-merchant>",
  "terminalId": "<configured-terminal>",
  "cashierId": "<configured-cashier>",
  "clientOrderNo": "<transaction-reference>",
  "salesType": "MA",
  "orderItems": [
    {
      "faceAmount": 10.0,
      "quantity": 1,
      "deliverType": "0",
      "itemCode": "<denomination-sku>"
    }
  ]
}

An acceptable creation response contains an order number:

{
  "isSuccessful": true,
  "orderNo": "<ogloba-order-number>"
}

Confirm and retrieve

The confirmation request uses the creation order number. The client sends POST orderConfirm with paymentType 01, a payment ID in the form X-<order-number>, and zero shipping, card, and return fees:

{
  "merchantId": "<configured-merchant>",
  "terminalId": "<configured-terminal>",
  "cashierId": "<configured-cashier>",
  "orderNo": "<ogloba-order-number>",
  "paymentList": [
    { "paymentType": "01", "paymentId": "X-<ogloba-order-number>" }
  ],
  "shippingFee": "0",
  "cardFee": "0",
  "returnFee": "0"
}

Retrieval sends POST orderStatus with the same provider order number:

{
  "merchantId": "<configured-merchant>",
  "terminalId": "<configured-terminal>",
  "cashierId": "<configured-cashier>",
  "orderNo": "<ogloba-order-number>"
}

For a ready order, the response has one card and orderStatus 042. Sensitive fields are redacted here:

{
  "isSuccessful": true,
  "orderNo": "<ogloba-order-number>",
  "orderStatus": "042",
  "listOfCards": [
    {
      "shortCardNumber": "[REDACTED]",
      "pinCode1": "[REDACTED]",
      "pinCode2": null,
      "expiryDate": "<YYYY-MM-DD>",
      "eGiftCardUrl": "[REDACTED OR EMPTY]"
    }
  ]
}

Response mapping and validation

For status 042, listOfCards must be an array containing exactly one card. The status response must contain orderNo and orderStatus. Fields such as the full card number, face amount, PDF URL, and delivery metadata are not copied into the application voucher response.

Provider states and retry behaviour

The create and confirm operations are separate provider actions. If the outcome of either action is uncertain, do not start a second sale: use the transaction reference, provider order number, and audit sequence to establish whether the original order exists.

Audit comparison fields

Processor interaction auditing is enabled for the transaction during issue and retrieval. Compare these fields in order:

1. Internal sale UUID and transaction reference against clientOrderNo in orderCreation.
2. Country code against the selected country account, and face value against faceAmount and the denomination SKU in orderItems.
3. Creation orderNo against confirmation orderNo and the stored processor reference.
4. The retrieval orderNo against that same processor reference and the returned orderStatus.
5. For a ready response, check the presence of card data and the normalized expiry date without copying code, PIN, or a live URL into a ticket.
6. Compare request and response timestamps, operation names, isSuccessful, and any errorCode/errorMessage values.

Settings

Processor settings

config/ogloba.php reads the following environment-backed settings:

The configured country account is used for HTTP basic authentication with the merchant ID and passphrase. The supported country keys in the configuration are AT, BE, DE, ES, FR, IT, NL, and PT.

Brand settings

The brand must have an Ogloba SKU for each requested denomination. The fixed processor type was changed to SKU per denomination in the onboarding migration, so a valid mapping for one face value does not prove that another face value is configured. The first country served by the brand selects the Ogloba country account; check that this country is intentional before changing credentials or mappings.

API operations

The API client sends JSON with Accept and Content-Type headers and the configured X-WSRG-API-Version header. The base URI and country-specific authentication are selected at runtime.

Customer-service investigation

For a delayed or failed sale, collect the internal sale UUID, transaction reference, requested country, currency and face value, denomination SKU, processor reference, and the complete ordered audit sequence for orderCreation, orderConfirm, and orderStatus. Check that the creation and confirmation order numbers match, then check the latest status and whether it is 041, 043, or 042.

Do not re-order while the original provider order or an uncertain create/confirm result is unresolved. If the status response is 042, check the validation fields and the presence of voucher data without placing the sensitive values in a support ticket. For a provider error, record the provider operation, errorCode, errorMessage, HTTP failure details, and timestamps.

Limitations

Balance lookup, cancellation, and webhook handling are not implemented for Ogloba. Escalations should include the internal sale UUID, transaction reference, provider order number, country, operation timestamps, response state, and redacted audit evidence.

Related code

• app/Processors/Ogloba/OglobaProcessor.php — asynchronous processor wrapper.
• app/Processors/Interaction/Integrations/Ogloba/OglobaProcessorInteraction.php — issue, retrieval, parsing, validation, and pending-state handling.
• app/Http/Clients/Ogloba/OglobaApi.php — authentication, transport, provider operations, and error-code mapping.
• app/Http/Clients/Ogloba/Requests/OrderCreationRequestData.php — create payload.
• app/Http/Clients/Ogloba/Requests/OrderConfirmRequestData.php — confirmation payload.
• app/Http/Clients/Ogloba/Requests/OrderStatusRequestData.php — status payload.
• app/Http/Clients/Ogloba/Requests/ProductsRequestData.php — catalogue payload.
• config/ogloba.php — shared and country-specific settings.
• database/migrations/2025_03_31_00000_r_c_c_15879_create_ogloba_processor.php — processor capabilities and contacts.
• database/migrations/2025_04_24_110610_rcc-15956-add-ogloba-catalogue.php — catalogue enablement.
• database/migrations/2025_07_21_091748_ogloba_change_fixed_processor_to_sku_per_denom.php — denomination SKU processor type.
• tests/Unit/Processors/Interaction/Integrations/Ogloba/OglobaProcessorInteractionTest.php — issue, retrieval, validation, and pending-state scenarios.