From demo to real payments

What we need
to go live with Birbank.

The registration experience is ready to test. Real card payments need the bank’s e-commerce acquiring access and technical specification. The B2B PDF supplies transaction reporting, not checkout creation.

Published by Birbank

Start with e-commerce access.

The bank’s public application asks for legal form, business name, app name, email, and mobile number. It describes the service for a website or mobile app.

For this project, specify event ticket sales in AZN on checkout.thebakupulse.com, linked from thebakupulse.com.

Official e-commerce application ↗

No application has been submitted by this app.

Get from the bank

The payment integration pack.

Approved merchant/terminal identifiers and sandbox access.
Current hosted-checkout / create-payment API, authentication, and environment URLs.
Payment status verification, callback authentication, final paid statuses, and refunds.
Test cards, 3-D Secure scenarios, return/callback URL rules, and any IP or domain allowlisting.
Production activation process and acquiring support contact.

These are the technical inputs we need. Exact names and authentication methods depend on the bank’s merchant platform.

Confirm with Birbank

Merchant & website approval.

The public pages do not list the full approval requirements. Ask the bank to confirm:

Business registration/VÖEN, authorized representative documents, settlement account, and acquiring agreement.
Required business identity and contact information on the website.
Event details, AZN prices, refund/cancellation terms, privacy and participant agreement requirements.
Fees, settlement schedule, supported cards, and any ticketing restrictions.

Prepare these items for review; this is not a verified exhaustive bank checklist.

Document reviewed

What the B2B PDF covers.

Section 28, pages 30–31: GET /api/b2b/transactions lists existing e-commerce transactions. It does not document card checkout creation.

The portal uses a different path, /b2b/transactions. The bank should confirm which reporting path applies. A record with status “SUCCESS” can be a reversal; it is not enough to confirm a paid ticket.

Bank PDF ↗ Reporting API ↗

Ready to copy

Send this to your bank contact.

Request the acquiring integration directly. Do not send API secrets through this page.

Salam. The Baku Pulse üçün checkout.thebakupulse.com domenində AZN ilə tədbir biletlərinin kartla ödənişini qəbul etmək istəyirik. Əsas saytımız thebakupulse.com-dur. İlkin bilet məbləği 25 AZN-dir.

Bizə B2B hesab/çıxarış API-si deyil, e-commerce / internet ekvayrinq qoşulması lazımdır. B2B-OPENAPI-V2.pdf sənədinin 28-ci bölməsi yalnız mövcud əməliyyatların siyahısını göstərir.

Xahiş edirik aşağıdakıları təqdim edəsiniz:
1. Merchant/terminal açılışı üçün tələb olunan sənədlər, müqavilə və saytın yoxlanış şərtləri.
2. Aktual ödəniş yaratma və bankın ödəniş səhifəsinə yönləndirmə API sənədi; test mühiti və giriş məlumatlarının təhlükəsiz təqdim edilməsi qaydası.
3. Ödəniş statusunun serverdən yoxlanması, callback autentifikasiyası, uğurlu/yekun statuslar və refund/ləğv API-si.
4. Test kartları, 3-D Secure ssenariləri, return/callback URL-ləri və IP/domen allowlist tələbləri.
5. Production aktivləşdirmə mərhələləri, komissiya və hesablaşma şərtləri, texniki əlaqələndirici.

Layihənin təcili işə salınması planlaşdırılır. Qoşulma üçün növbəti addımları və mümkün müddəti bildirməyinizi xahiş edirik.

Our launch checklist

Before changing the live registration link.

This checklist tracks project readiness. Checks are saved only in this browser; they do not configure or connect the bank.

Bank approves the merchant and provides the acquiring integration pack.
Hosting is selected and checkout.thebakupulse.com has DNS and HTTPS.
Sandbox credentials are installed in the server’s secret store.
The real create-payment adapter and persistent registration/order storage are implemented.
Authenticated callbacks and server-side verification match order, merchant, amount and AZN currency.
Confirmations/tickets are issued once after verified payment, with a working delivery channel.
Bank sandbox tests pass: successful, declined, cancelled, pending, duplicate callback, timeout and refund.
Bank approves production; live credentials are configured and the simulator stays disabled.
Agree the real payment smoke test, then point the Tilda registration button at the checkout.

0 of 9 completed

Test the experience

Demo, sandbox, and live are different.

What can I test right now?

Open the registration, select “Fill with sample details”, and continue. Test a successful payment with demo code 123456, a declined card, a cancellation, or a pending payment. You can refresh a pending result and then simulate confirmation. No bank is contacted and no real card number is accepted.

Is this a Birbank sandbox payment?

No. The current simulator runs inside this app. Birbank sandbox testing starts after the acquiring API specification and bank-issued test access are available. The sample card ending 4242 and code 123456 belong only to this simulator.

What is saved?

Demo orders keep a participant display name, distance, amount and status in temporary server memory for up to 30 minutes. Date of birth, phone and nationality are validated but not retained as fields. Orders reset when the server restarts. Downloaded summaries are labeled as demos and are not admission tickets.

Can we deploy this now?

The app can be packaged for a preview, but real acquiring, durable order storage and ticket delivery are not implemented. Production mode disables simulator APIs and reports payment readiness as unavailable. Deploying the code does not activate bank payments.

Try the demo checkout →

Sources checked 4 November 2026. Final merchant acceptance, integration protocol, and launch approval come from Birbank.

What we needto go live with Birbank.