Use with Lovable
Build quickly.
Keep payments secure.
BjornTech’s API works with Lovable, Bolt and similar AI builders—when the integration lives behind a trusted, authenticated backend.
Copy the builder promptAI builder
Browser interface
Trusted application backend
AuthHMAC signingOrdersAccess control
BjornTech Swish API
Server-to-server only
Before you build
Five prerequisites. No frontend workaround.
If one is missing, enable it before adding Swish.
Trusted backend
Secret storage
Persistent database
Authentication
Access control
Browser-only projects are not acceptable. HMAC credentials, merchant configuration, provider identifiers, payment logic and refund logic must never be shipped to the browser.
Safe boundary
The browser knows less.
It calls only your authenticated backend and receives sanitized application-level state. Amount, currency and payee are calculated authoritatively on the server.
01Persist the order and one stable instruction ID
02Treat create as acknowledgement—not payment success
03Verify status with authenticated GET
04Make callbacks and fulfillment idempotent
05Restrict refunds to authorized operators
06Use fakes or controlled non-live tests while building
Builder prompt
Give your AI builder the right constraints.
Attach the BjornTech API documentation to your AI builder together with this prompt.
Build a secure website order and Swish payment flow using the BjornTech Swish Platform API Documentation as the source of truth.
Before coding, verify the project has: (1) trusted backend/server functions, (2) server-only secret storage, (3) persistent database, (4) authentication, (5) enforced ownership/access control. If any prerequisite is missing, stop the Swish integration and state exactly what needs enabling. Do not create a frontend workaround.
All BjornTech API requests, HMAC signing, payment/refund logic, merchant configuration, provider identifiers and secrets stay backend-only. Never ask me to paste credentials into chat, source, frontend environment variables, browser storage, logs, screenshots or test data. Configure them directly in backend secret storage.
The browser calls only my authenticated application backend and receives sanitized application-level state. Follow the BjornTech documentation exactly and do not invent routes, statuses, SDKs, launch URLs or behavior.
Calculate authoritative amount/currency/payee server-side. Persist the order and one stable instruction ID. Treat create response as acknowledgement only and verify status via authenticated GET. Make retries/idempotency safe. After an uncertain create outcome reuse the same instruction ID and exact payload with fresh nonce/timestamp/signature. Respect Retry-After on 429. Fulfillment must be idempotent.
Callbacks are notifications only; verify via authenticated GET before marking paid. Refunds are backend-only and restricted to authorized operators. Do not perform live payments/refunds while building; use fakes/non-live controlled tests.
At the end report backend components, secret configuration mechanism, database/access controls, browser/backend boundary, retry/idempotency behavior, tests, and anything blocked or omitted.