Test your integrationbefore going live.

Pementek Sandbox gives developers a safe environment for building and validating payment and payout integrations without moving real money.

Test API requests, transaction states, idempotency, signed webhooks and backend business logic using sandbox credentials and simulated transaction outcomes.

API Reference→Contact Pementek
EnvironmentSandbox
TEST
Real moneyNo
API requestsEnabled
WebhooksSigned
TransactionsSimulated
Ready for testingIsolated from production activity

Build against the payment lifecycle safely

Financial integrations should be tested before they begin processing real customer transactions. The Pementek Sandbox allows your development team to exercise the same core integration patterns used for payments, payouts, transaction retrieval and webhook processing.

Sandbox transactions use simulated outcomes rather than real financial movement, allowing you to validate application behavior without affecting production balances or customer funds.

Your production and sandbox credentials should remain separate so test activity cannot accidentally be treated as live merchant activity.

Test the parts that matterbefore production.

Use the sandbox to validate API behavior and your own backend logic across common transaction scenarios.

01

Isolated testing

Build and test your integration with sandbox credentials and test data separated from production activity.

02

Simulated payments

Create test payment transactions and exercise supported payment lifecycle scenarios without moving real money.

03

Simulated payouts

Test payout creation, status handling and backend workflows using non-production payout scenarios.

04

Webhook testing

Receive signed sandbox webhook events and verify your signature, deduplication and event-processing logic.

05

Safe retry testing

Validate idempotency handling and retry behavior before financial operations reach production.

06

Transaction states

Test how your application responds to processing, verification, reconciliation and final transaction states.

From first requestto production readiness.

Use a repeatable test workflow to confirm that your integration handles both normal and asynchronous transaction behavior correctly.

01

Use sandbox credentials

Configure your backend with sandbox API credentials rather than your production credentials.

02

Create a test transaction

Send a payment or payout request using test values and your own sandbox merchant reference.

03

Simulate an outcome

Exercise transaction scenarios such as successful verification, delayed processing or reconciliation.

04

Receive webhook events

Confirm that your backend verifies signed events and handles repeated delivery safely.

05

Validate your integration

Confirm your application responds correctly before moving the same integration pattern into production.

Create asandbox payment.

Use your sandbox API URL and sandbox credentials when building or testing non-production transactions.

Sandbox request

curl -X POST \
$PEMENTEK_SANDBOX_API_URL/v1/payments \
-H "Authorization: Bearer $PEMENTEK_SANDBOX_API_KEY" \
-H "Idempotency-Key: sandbox-order-847291-payment-1" \
-H "Content-Type: application/json" \
-d '{
  "merchant_reference": "SANDBOX-ORDER-847291",
  "amount": 50,
  "currency": "USD",
  "country": "US",
  "payment_method": "LOCAL_PAYMENT_METHOD"
}'

Example response

JSON

{
  "id": "pay_test_01JQAB8M4R7X2N6K5T9C3D1F",
  "merchant_reference": "SANDBOX-ORDER-847291",
  "amount": 50,
  "currency": "USD",
  "country": "US",
  "payment_method": "LOCAL_PAYMENT_METHOD",
  "status": "CREATED",
  "livemode": false
}

Keep sandbox and production separate

Sandbox credentials are intended only for testing and should not be used for live customer transactions.

Your application should maintain separate environment configuration so sandbox API credentials, webhook secrets and test transaction identifiers cannot accidentally be mixed with production configuration.

Never place production API credentials inside sandbox test code, local examples, public repositories or frontend applications.

Test more thansuccessful transactions.

A reliable payment integration should behave correctly when transaction processing is delayed, unresolved or unsuccessful—not only when everything succeeds immediately.

SUCCESS

Test the workflow for a transaction that reaches a verified successful final state.

VERIFYING

Confirm that your application can safely represent a transaction that is still being verified.

PENDING_RECONCILIATION

Test an unresolved transaction where a definitive final result is not yet available.

FAILED

Exercise the application behavior for a definitive unsuccessful transaction outcome.

ROUTING_UNAVAILABLE

Test how your application handles a transaction for which processing cannot be made available.

Test uncertain transaction outcomes

Real payment systems do not always produce an immediate final result. Your application should therefore be able to handle transactions that remain in verification or reconciliation states.

The sandbox can be used to validate that your application does not incorrectly treat an unresolved transaction as a success or failure.

PENDING_RECONCILIATION should be treated as an unresolved transaction state, not an automatic failure.

Validate idempotency before going live

Network failures can cause applications to retry payment or payout requests. Without safe retry behavior, those retries can create duplicate financial operations.

Use the sandbox to confirm that your integration preserves the original idempotency key when retrying the same logical transaction.

Your application should also confirm the existing transaction state before generating a new transaction after an uncertain API response.

Test signed webhooks

Your webhook handler should be tested with sandbox events before it begins processing production transaction notifications.

Confirm that your backend verifies the webhook signature, records the event identifier and safely ignores duplicate delivery of an event that has already been processed.

The customer browser should never be the authoritative source of final payment or payout status.

Read Webhook documentation→

Test payments

Create simulated local payment transactions and validate transaction creation, payment state, verification behavior and webhook processing.

Payment API→

Test payouts

Exercise merchant-approved payout creation, asynchronous processing and verified final payout results without moving real funds.

Payouts→

Test securely

Sandbox credentials should still be treated as private credentials and stored only in trusted development or server-side environments.

Do not embed API keys or webhook secrets in browser code, mobile applications or public repositories simply because they belong to a non-production environment.

Learn about Security→

Before moving to production

Confirm that your integration can create transactions, retry requests safely, verify signed webhooks, process duplicate events idempotently and correctly distinguish intermediate transaction states from final outcomes.

  • Production credentials are stored server-side
  • Sandbox credentials are removed from production configuration
  • Idempotency behavior has been tested
  • Webhook signatures are verified
  • Duplicate webhook events are handled safely
  • Pending states do not trigger final fulfillment
  • Transaction status can be retrieved when local state is uncertain

Build safely.Then go live.

Use Pementek Sandbox to validate your payment and payout integration before processing production transactions.

API Reference→Contact Pementek