T-Bank to amoCRM Integration for Automated Payment Processing
Case · Payment Integration and CRM · 2026
We built and verified a bundle in which a confirmed payment from T-Bank reaches the desired amoCRM transaction, changes only the necessary data and remains secure when webhook is re-delivered.
The challenge
After payment, the manager does not have to manually search for an order, verify the amount and move the transaction between stages. But payment automation requires caution: notifications can come again, the order box can appear in CRM a little later than webhook, and any secrets should remain outside of logs and comments.
It was necessary to link T-Bank’s NotificationURL to the existing amoCRM funnel and provide a clear sequence: verify the authenticity of the event, accept only CONFIRMEDFinding the only deal on ORDERIDRecord the actual result and guarantee idempotence.
Proven payment path
-
Public webhook without user session
The HTTPS route receives a bank notification without user authorization and CSRF, but with a request body size limitation and rate limit.
POST /webhooks/tbank/payment -
Check Token before processing
The signature is calculated according to the official algorithm: the root values of the notification and the terminal password are sorted by key, combined and hashed by SHA-256. The comparison is done in a safe way.
TBANK_PASSWORD · SHA-256 · hash_equals -
Fixing PaymentId
The notification is stored in a local table with a unique
unique payment_id · queued / processed / failedPaymentId. Re-delivery does not create a new record and does not trigger a second processing of an already completed payment. -
Search for a deal on ORDERID
The service searches throughout the configured funnel, regardless of the current stage, and then checks the exact value of the field.
amoCRM leads API · exact custom field matchORDERIDThe uniqueness of the result on all pages of the answer. -
Update of deal
The transaction is transferred to «Payed », the amount of payment in rubles is recorded in the budget, and the bank ID is stored in the field
status_id · price · PAYMENTIDPAYMENTID. -
Comment without takes
After a successful update, a structured note is added: PaymentId, OrderId, the amount, status and time of receipt of the confirmation. Before POST, the service checks existing notes on PaymentId.
common note · idempotent by PaymentId
What the manager gets in amoCRM
Confirmed status
Only successful ones are handled CONFIRMED with a correct Token. Unconfirmed statuses are accepted without changing the transaction.
Current card
« Paid by », real budget saved by PAYMENTID and clear payment comment are all in one transaction.
Race defense
If the deal is already in place, but ORDERID has not yet appeared in the search, the queue will repeat the operation on the growing backoff for more than 25 hours.
Idempotence on two levels
- Payment. — unique PaymentId does not allow you to re-queue an already processed notification.
- Comments — is checked before adding a note whether there is an exact line with the same PaymentId in the transaction.
- Deal. A — search requires a single exact match for ORDERID; ambiguous results do not change automatically.
- Sum — minimum monetary units are converted integerly, without float and hidden rounding.
Diagnosis without changing data
A separate artisan command has been added to check the connection php artisan amocrm:inspect. Secure GET queries show funnels, stages and custom trade fields without outputting access token or Authorization header.
During the audit, the required funnel, the « Paid » stage, the ORDERID and PAYMENTID fields, account availability and the history of several recent transactions were confirmed. Production transactions did not change during the inspection.
Architecture
Laravel
WebhookCheck the request size, TerminalKey and Token before processing the payment.
WarehouseMySQL stores the event with a unique PaymentId and does not allow reprocessing.
queueSeparate line tbank synchronize with repeated attempts.
amoCRM
AuthorizationServer access over long-term access token from a secure configuration.
ConnectionThe T-Bank OrderId is matched to the amoCRM ORDERID user field.
The resultUpdate stage, budget and PAYMENTID, then add a note about the payment.
Created integration of amoCRM
For the project, server integration with amoCRM API v4 was created and configured. It links a bank notice to a particular transaction and works without manual data transfer.
Connection
Access.Long-term access token is used; its value is stored only in the application environment and does not enter the article or logs.
Callback/integrations/amocrm/callback left for OAuth connection and protected by user authorization.
Configured entities
Funnel and stageIntegration works with the target funnel and transfers the confirmed payment to the stage «Payed ».
Field of dealORDERID is used to search for a transaction, and PAYMENTID — is used to fix a bank payment and protect against duplicates.
Security
- terminal password, access token and Authorization header do not enter the output and logs
- webhook payload is not copied to amoCRM.
- Transaction link not invented by — NotificationPayment does not provide a confirmed public URL payment
- webhook answers the bank accurately
200 OK, and further synchronization is performed by the queue - The integration check was carried out without test payments or financial transactions.
The result
Confirmed payment no longer requires manual reconciliation: Laravel checks the bank event, finds the correct transaction regardless of its current stage, fixes the amount and PaymentId, transfers it to «Payed » and leaves a clear comment.
Repeated notifications are safe, ORDERID delay is covered by prolonged retry, and integration status can be checked by a separate diagnostic team without changing CRM.
Laravel · T-Bank API · amoCRM API v4 v4 · MySQL · Queue · Webhook · Idempotency