Getting Started: Concepts and Sandbox Setup

ជំពូកនេះមិនទាន់ត្រូវបានបកប្រែជាភាសាខ្មែរនៅឡើយទេ — សូមអានជាភាសាអង់គ្លេសខាងក្រោម។

What you're building
Key concepts
A note on credentials
Prerequisites
Beginner Pitfalls

1. What you're building

By the end of this course, you'll have a working checkout page that follows PayWay's own three documented integration steps (official reference):

Create a Payment Transaction — request a transaction from PayWay and show the customer a way to pay (QR code / card form / deep link).
Verify Payment Status — poll PayWay to confirm whether the customer actually completed payment.
(Optional) Handle a callback — receive an async server-to-server notification when the payment status changes.

You do not need to build your own payment form from scratch — PayWay provides fields and a checkout script you plug into, covered in Part 2.

Everything here is a teaching companion, not a replacement for PayWay's own docs. Field names, hash formulas, and endpoint URLs can change without notice — check the ABA PayWay Developer Suite before implementing anything for real.

2. Key concepts

Most beginner confusion comes from skipping this part.

Term	What it means
Sandbox	A fake/test version of PayWay. No real money moves. Use this for all learning and development.
Merchant ID	Your unique ID as a "shop" in PayWay's system. Sandbox gives you a test one.
Public Key	A secret string tied to your Merchant ID, issued alongside your sandbox credentials. Historically used as the "API Key" for hashing requests.
RSA Key Pair	A separate RSA public/private key pair PayWay's newer sandbox emails also issue. Which key material your integration should use for signing depends on which API/endpoint you're calling — confirm against the official docs, don't assume.
Hash / Signature	A value you generate with your key material and attach to every request, so PayWay can verify it wasn't tampered with. The algorithm (HMAC vs. RSA signing) and which key it uses depends on the API.
`tran_id`	A unique ID you generate for each transaction, like an order number. PayWay uses it to track the payment.

Whichever key you use, it must only ever live on your backend/server, never in JavaScript that runs in the browser, and never committed to a git repo. Anyone who obtains it could fake transactions.

3. A note on credentials

When you register for a PayWay sandbox account, the approval email includes a credential_info.txt attachment with five values: Merchant ID, Public Key, RSA Public Key, RSA Private Key, and the API URL — more than the single "API Key" older guides describe.

Of these, this course's example only ends up using PAYWAY_PUBLIC_KEY (confirmed against the Purchase API docs, Part 3). PAYWAY_RSA_PUBLIC_KEY has a confirmed purpose too, but for a later step — the Refund API, covered in Part 6. PAYWAY_RSA_PRIVATE_KEY's purpose is not confirmed by anything in this course — don't assume a use for it without checking the current docs yourself.

4. Prerequisites

A sandbox PayWay account — register at the Developer Suite; approval arrives by email with credential_info.txt.
A basic web page you can edit, and a backend you can run locally (this course's example uses Node.js/Express, but PayWay's own official code samples are mostly in PHP).
A way to test locally with HTTPS, such as ngrok — PayWay's callback requires HTTPS, so plain localhost won't receive it. More on this in Part 5.

5. Beginner Pitfalls

Don't guess which key signs which request. The Public Key and the RSA key pair serve different APIs (and possibly different algorithms) — verify against the docs for the specific endpoint you're calling.
A sandbox account is enough to build and test. It is not enough to launch — going live involves a real business process with ABA PayWay, covered in Part 7.
Treat every field name, hash formula, and endpoint URL in this course as something to re-verify before you ship, not something to copy blindly — payment gateway APIs change over time.