What you need before you start

What you need before you start

Credentials and IDs you must store

This integration produces a handful of values that you need to keep. Some are generated once and used forever, some are created per store, and one is created per payment. Losing any of them means work you cannot redo from the outside, so decide where each one lives before you start writing code.
Value
Where it comes from
What it is used for
Scope
key and secret
You generate them (two strong random strings)
Woosa uses them as HTTP Basic Auth credentials when calling your shop's callback endpoints
Per shop, per environment
woosa_secret
Woosa pushes it to your settings/general/batch endpoint during registration
Signing every request you send to the Midlayer
Per shop, per environment
contractorId
GET /woocommerce/adyen/backoffice-user-contractors
Telling Woosa which legal entity this shop belongs to, via PUT /woocommerce/adyen/contractor
Per legal entity, per environment
store_id
Response of POST /woocommerce/adyen/stores
Goes in the URL of most payment and payment-method calls
Per store, per environment
shopperReference
You generate it (a stable id for each customer)
Saving and reusing a shopper's payment method, and removing it later
Per customer, permanent
pspReference
Response of POST .../payments or POST .../payment-details
Capturing, refunding, cancelling, and GDPR erasure
Per payment, permanent
Verification code
Emailed to the merchant during account connection
One-time use in PUT /woocommerce/adyen/backoffice-user

Storage requirements

woosa_secret is the single most important secret in the integration. Store it permanently and encrypted, outside your web root. Every signed request depends on it, and there is no way to sign without it. Treat it the way you would treat a database password.
Save pspReference the moment a payment is created, on the order record it belongs to. It is the only handle you have for capturing, refunding, or cancelling that payment later. If your order record does not have it, you cannot refund the customer through the API.
Keep store_id and contractorId somewhere your application can read at runtime, not just in a developer's notes. store_id appears in the path of almost every payment call, and contractorId is needed whenever you set the current contractor.

Matching payments back to your own orders

Woosa does not know your order numbers. Attach your own identifier to every payment using the metadata field, for example:
json
"metadata": { "wc_order_id": 592 }
Woosa echoes metadata back to you in payment responses and in GET /woocommerce/adyen/updated-payments, which is how you match a status change to the right order in your system. Without it, polling for updates gives you payments you cannot place.