Endpoints your shop must expose

Endpoints your shop must expose

You need to expose three endpoints on your own shop. Build these before you try to register, because registration will immediately call two of them.
The paths use the WooCommerce naming on purpose. The Woosa server expects these exact paths and contracts, because it treats every shop as if it were WooCommerce.

1a. "Give me your settings endpoint

GET /wp-json/wc/v3/settings/general
What it is for: before your shop is registered, Woosa calls this to validate that the key and secret you gave are real.
Rules:
  • Protect it with HTTP Basic Auth. Basic Auth is the simplest form of login for an API: the caller sends your key as the username and your secret as the password. Your endpoint checks they match the pair you registered with. If they do not match, reply with 401 Unauthorized.
  • On success, return a JSON list of setting objects. At minimum, include one entry whose id is woosa_secret.
  • The very first time, you do not have a secret yet, so return an empty string for its value.
Example response (first time, no secret yet):
[
  {
    "id": "woosa_secret",
    "value": ""
  }
]

1b. "Save a setting" endpoint

POST /wp-json/wc/v3/settings/general/batch
What it is for: once Woosa has confirmed your credentials and registered your shop, it generates a secret key for your shop and pushes it to you through this endpoint. You store it. From that moment on, this woosa_secret is what you use to sign every request (Part 3).
Rules:
  • Protect it with the same HTTP Basic Auth as above.
  • Accept a body with an update array. Each item has an id and a value.
  • Save each setting, then return the updated objects in the same shape as the GET endpoint above.
Example request Woosa sends you:
{
  "update": [
    {
      "id": "woosa_secret",
      "value": "8caa59a1c330f23d55de3bdd339a1c330f23d55"
    }
  ]
}
Store the secret key somewhere safe and permanent (encryption is recommended). This is the single most important secret in the whole integration. If you lose it, you cannot sign requests, and nothing works.

1c. "Onboarding return" endpoint

GET /wp-json/woosa-payments/onboarding-redirect
What it is for: later, the merchant gets sent to an Adyen page to prove their identity (see Part 5). When they finish, they get bounced back to this URL. Its only job is to redirect the merchant to the right page in your own shop's admin (for example, back to a "Payments settings" screen).
Rules:
  • No authentication needed.
  • Respond with a 302 redirect to wherever you want the merchant to land.
That is the full extent of the extra work. Three small endpoints. Two of them are essentially a tiny key-value store guarded by Basic Auth, and the third is a redirect. Build these, then move on.