Sandbox testing

BaaS Card Sandbox

Triggering Card Payment Events in Sandbox

This guide describes how to simulate Card Payment events in the ConnectPay Sandbox environment, specifically:

  • Authorization — creates a card payment reservation.
  • Financial Transaction (Capture) — captures the authorized amount and creates the completed card transaction.

Preconditions

Before triggering card transaction events, ensure the following conditions are met:

  1. Activated Card
    • The card application has been successfully approved.
    • An active card is available. The cardId parameter is required for the Sandbox requests.
  2. Activated Account
    • The account linked to the card is open and active.
    • An IBAN has been created and is available.
  3. Sufficient Balance
    • The account must have sufficient available funds to cover the transaction amount.

Step 1: Create Card Authorization (Reservation)

This step simulates the authorization request stage of a card payment. The requested amount is reserved on the account.

Endpoint: Create Sandbox Authorization

POST /sandbox/ob/cards/{cardId}/authorizations

Request Body — recommended values for a test case:

{
  "cardTransactionType": "AUTHORISATION_REQUEST",
  "serviceType": "CARD_PURCHASE",
  "transactionAmount": {
    "amount": "1.00",
    "currency": "EUR"
  },
  "originalAmount": {
    "amount": "1.00",
    "currency": "EUR"
  },
  "purchaseDatetime": "2025-10-31T05:22:30.000Z",
  "merchant": {
    "name": "Cards Automation Test",
    "address": {
      "city": "Vilnius",
      "postcode": "65666",
      "addressLine1": "Street name 13",
      "countryCode": "LT"
    },
    "categoryCode": "123123"
  }
}

Expected Results

  • A Card Payment Status Changed webhook notification is triggered.
  • A reservation (card hold) is created on the account.
  • The authorization response provides the card transaction identifier required for the Capture request.

Step 2: Capture the Transaction

After the authorization has been created, simulate the Financial Transaction (Capture) stage by capturing the previously authorized amount.

The Capture completes the card payment and converts the reservation into a completed card transaction.

Endpoint: Card Sandbox Payment Capture

POST /sandbox/ob/cards/{cardId}/captures

Use the cardTransactionId returned by the Authorization request in the authorization.cardTransactionId field.

Request Body — recommended values for a test case:

{
  "serviceType": "CARD_PURCHASE",
  "authorization": {
    "cardTransactionId": "{{cardTransactionIdFromAddHoldResponseBody}}"
  },
  "transactionAmount": {
    "amount": "1.00",
    "currency": "EUR"
  },
  "originalAmount": {
    "amount": "1.00",
    "currency": "EUR"
  },
  "purchaseDatetime": "2025-10-31T05:22:30.000Z",
  "merchant": {
    "name": "Cards Automation Test",
    "address": {
      "city": "Vilnius",
      "postcode": "65666",
      "addressLine1": "Street name 13",
      "countryCode": "LT"
    },
    "categoryCode": "123123"
  }
}

Expected Results

  • The card payment is successfully completed.
  • The Capture triggers a balance movement on the selected account.
  • The completed card transaction can be retrieved using the Get Account Transactions API.

Notes

A successful Capture creates a balance movement and a card transaction on the selected account. The transaction can then be retrieved using Get Account Transactions.

Only EUR currency is supported for Sandbox card payment simulations.

Merchant address values can be modified for testing purposes.

Fields in the Authorization and Capture requests must match, except for the amount when testing a partial capture.

The standard test sequence is:Authorization → Capture

A successful Authorization triggers the Card Payment Status Changed notification.

Sandbox Testing Limitations

The Sandbox API does not communicate with the card issuer system. Therefore, it does not validate or enforce the following card configuration and security functions:

  • Card Limits
  • Card Security Settings
  • MCC Code Validation

Note: MCC code validation is not applicable to the Create Card Authorisation Sandbox flow. The Merchant Category Code can still be provided as part of a requested test event but is not validated against card settings in Sandbox.

Sandbox Pin Change

Change Pin API in Sandbox system takes effect in approx. 5-10 minutes. This means that after Successful API Change Pin execution, result of Get Pin will return Updated PIN with in 5-10 minutes in sandbox system. Pin change is not immediate action.

Ordering Card Testing Events

If specific card testing events are required, please send the request to:

[email protected]

Use the following template when ordering card testing events. Provide one row for each required test case.

VariableDescription / Allowed Values
Currency to be ReservedCurrency in which the reservation should be created, for example EUR.
Original CurrencyOriginal transaction currency presented by the merchant, for example EUR, USD, or GBP.
Merchant Category CodeMCC code to be used for the simulated merchant transaction.
Event TypeType of card transaction to simulate: PoS, Online Purchase, Fuel Dispenser, or ATM.
Is Capture NeededDefines whether a Capture event should follow the Authorization. Values: Yes / No.
Is Partial ReservationDefines whether a partial reservation scenario should be tested. Values: Yes / No. Applicable when Fuel Dispenser is selected as the Event Type.
Merchant Country of OriginCountry where the simulated merchant is located. Provide the applicable country code, for example LT, DE, or GB.

Test Case Order Template

Test CaseCurrency to be ReservedOriginal CurrencyMerchant Category CodeEvent TypeCapture NeededPartial ReservationMerchant Country of Origin
Test Case 1EUREURPoSYesNoLT
Test Case 25.5 EUR6.3 USDNot SpecifyedPoSYesNoPL
Test Case 3

Use a separate row for each required transaction scenario.

Testing First Chip and Pin card procedure

Phase 1: Technical & Administrative Preparation

Step 1.1: Personalisation Code Setup (ConnectPay)

  • Action: ConnectPay configures and deploys the physical Chip and Pin personalization codes in the Production BaaS API system.
  • Details: This ensures that when a physical card request is triggered, ConnectPay’s systems correctly recognize the “Physical Card” template and route the correct manufacturing/embossing parameters to Wallester.

Step 1.2: Build Submission to Google Developer Console (Affiliate)

  • Action: Affiliate uploads the new mobile app version (supporting physical card ordering, shipping address forms, and PIN management) to the Google Play Console.
  • Details: The build must be deployed exclusively to an Internal Test Track (or Closed Beta) so that it remains private and unreachable by the general public.

Step 1.3: Sandbox Validation Verification (ConnectPay & Affiliate)

  • Action: Verify that physical card ordering, PIN setting, and sandbox payment simulation (Authorization ➔ Capture flow) are fully operational and verified.

Phase 2: Production Enablement & Distribution

Step 2.1: Production White-Label Enablement (Wallester)

  • Action: Wallester enables the Chip and Pin physical card product on Affiliate’s Production White-Label program setup.
  • Action: Affiliate generates and shares the internal app testing link (Google Play Store internal testing URL or TestFlight) with:
    • ConnectPay QA / Project Team (Orders first test card to Lithuania).
    • Selected Affiliate Employee (Orders first test card to Affiliate’s local region).

Phase 3: Live Friends & Family Testing

Step 3.1: Card Printing & Shipping

  • Action: Cards are manufactured, personalized with the users’ names, and dispatched via post to the respective test addresses.
  • Watch out for: Tracking delivery times and verifying that packaging/fulfillment matches expectations.

Step 3.2: Card Activation & Security Setup

  • Action: Testers activate their physical cards via the test app, set/verify their PINs, and configure 3DS security/internet purchase limits.

Step 3.3: Live Transactions Execution

  • Action: Execute real-world transactions to test end-to-end processing:
    • POS Transaction (Chip & Pin): Insert the card into a physical reader and enter the PIN to activate the chip.
    • ATM Cash Withdrawal: Perform a balance inquiry or a minor cash withdrawal to test PIN verification over the ATM network.
    • Contactless Transaction: Execute a contactless tap after the first successful Chip & Pin transaction has initialized the card.
    • Online/Internet Purchase: Execute an e-commerce purchase to test the 3DS verification loop.

Phase 4: Evaluation, Sign-Off & Public Go-Live

Step 4.1: Report Compilation & Delivery

  • Action: ConnectPay compiles the physical QA testing report (noting successful authorization, capturing, settlement, and any physical shipping anomalies) and submits it to Wallester.

Step 4.2: Audit Approval (Wallester)

  • Action: Wallester reviews the testing outcomes and officially approves the testing phase.

Step 4.3: Public App Store Release (Affiliate)

  • Action: Affiliate promotes the private developer build to the Production Track on Google Play and Apple App Store, making physical Chip & Pin card ordering globally available to all live customers.

Pro-Tips & Pitfalls to Avoid

  1. First Transaction Rule: Remind testers that contactless transactions will fail initially. The very first transaction must be a physical Chip & Pin insert at a merchant POS terminal or ATM to write the application profile to the card’s EMV chip.
  2. 3DS Password Setup: Ensure the mobile app UI forces the user to configure 3D Secure settings before they are allowed to toggle online purchases on. Failing to set a 3DS password before enabling internet transactions will trigger a BaaS API error.

Scroll to Top