Registration is the easy part; what usually breaks is deciding whether a returning shopper paid. confirm_order asks the gateway by orderId and validate_payment_response turns the raw response into a status, so the verdict does not rest on a redirect parameter. Refunds sit in the same tool set, which means a support conversation can end in a refund rather than a handover. Credentials can arrive through configure_credentials at runtime, so the environment variables are not the only route in.
A SATIM payment gateway client covering the order lifecycle: credential setup, order registration, post-payment confirmation, refunds and response interpretation.
- Order registration carrying orderNumber, amountInDA, currency, description, language and the returnUrl and failUrl the shopper is redirected to
- Order confirmation by orderId after a payment attempt, so the outcome comes from the gateway rather than from the redirect
- Refunds against a completed order for a stated amount and currency
- Interpretation of a raw gateway response into a payment status verdict
- Runtime credential configuration through configure_credentials, which takes userName and password directly
- Merchant-defined fields udf1 through udf5 on the registered order, plus force_terminal_id for routing
A SATIM merchant account, three environment variables — SATIM_USERNAME, SATIM_PASSWORD and NODE_ENV — and GPL-3.0 terms if you redistribute the server.
Build from source — clone the repository and build it, then point your client at the binary