Skip to content
MULENPAY.COM

Typical setups

Payment setup scenarios

Five ways different kinds of businesses start accepting payments with MulenPay: what they had before, which tools they picked, how it works and what changed.

  • Fees from 2.9%
  • PCI DSS 4.0.1

Five kinds of business

What it looks like in practice

Every scenario shares the same terms: from 2.9% per payment, setup in 1 day, no monthly fee and no charge for integration. Only the tools differ.

01

An online store on WordPress and WooCommerce

Tools: WooCommerce moduleRussian cardsForeign cardsSBPSberPay and T-Pay54-FZ receipts
Starting point
A WooCommerce store with a catalogue, a cart and checkout. Payment was taken by bank transfer: the customer placed an order, waited for a message with the amount, sent the money, and a manager matched incoming transfers by hand. The receipt required by Russian fiscal law (54-FZ) was issued separately, and some sales had no receipt at all. Evening and weekend orders waited until morning.
What was set up
The ready-made MulenPay module for WordPress and WooCommerce, Russian bank cards, payment through SBP, SberPay and T-Pay, and fiscal receipts through a cloud online cash register. Foreign cards were enabled separately for buyers with cards issued outside Russia.
How it works
The plugin is uploaded to WordPress and activated in the admin panel; the Shop ID and Secret Key from the MulenPay dashboard go into the WooCommerce settings, and the webhook address is set in the dashboard. At checkout the buyer sees card and SBP payment, the payment is confirmed with 3-D Secure, and the order status in WooCommerce updates on its own. A receipt is generated automatically for every payment and every refund, so the store needs no cash register of its own. Every operation is visible in one dashboard.
What changed
The order is paid at checkout, with no messaging and no matching of transfers. The receipt reaches the buyer automatically. Refunds are issued from the dashboard rather than from a personal card. The store takes payments around the clock, and the manager handles orders instead of payments.
Read more: WordPress module Fiscal receipts

02

Sales in Telegram and social networks

Tools: Payment linksRussian cardsSBPSberPay and T-Pay54-FZ receiptsDashboard
Starting point
A seller runs a channel and takes orders in direct messages. There is no website and none is planned: the range keeps changing, and every order is discussed in chat. Payment was requested as a card-to-card transfer, which meant checking screenshots, losing orders in the conversation and explaining why no receipt arrived.
What was set up
Payment links from the MulenPay dashboard for each order, plus a static link for fixed-price items. Payment methods behind the link: Russian bank cards, SBP, SberPay and T-Pay. Fiscal receipts (54-FZ) go through a cloud online cash register, so there is no need to buy and register one.
How it works
The seller creates a link in the dashboard, sets the amount and the name, and sends it to the customer in chat. The customer opens the link on a phone, picks a card or SBP and pays on a secure MulenPay page: PCI DSS 4.0.1 certification and 3-D Secure sit on the service side, with nothing for the seller to configure. The payment status appears in the dashboard and the receipt is generated automatically. For social networks the same link goes into the profile description or a post.
What changed
Payment happens right in the chat, with no bank details and no screenshots. All payments sit in one dashboard, and it is clear which order is paid and which is not. The receipt reaches the buyer on its own. The website was never needed.
Read more: Payment links Payments in social networks

03

An online school with a subscription

Tools: Payment widgetRecurring paymentsRussian cardsSBPSberPay and T-Pay54-FZ receipts
Starting point
The school sells courses from a landing page and monthly subscription access. Course payment went through a redirect to an external page where some students dropped off. Subscriptions were renewed by hand: every month the student got a reminder, entered the card again, and some renewals simply never happened.
What was set up
The MulenPay payment widget on the course landing page and recurring payments for the subscription. Payment methods: Russian bank cards, SBP, SberPay and T-Pay. Fiscal receipts (54-FZ) are generated through a cloud online cash register for every payment and every automatic charge.
How it works
The widget is added with a code snippet on the course page, and the buyer pays without leaving the site. For the subscription the student saves a card once at the first payment; after that the school charges the fee by the stored token on its own schedule, with no card details entered again. Every charge is visible in the dashboard. If the student unsubscribes, the school simply stops sending charge requests and the subscription ends.
What changed
The course is paid for on the same page where the student made the decision. The subscription renews by itself, without reminders or re-entering the card. Receipts for every charge are generated automatically. The school manages subscriptions from one dashboard.
Read more: Payment widget Recurring payments Payments for education

04

A custom service or SaaS

Tools: REST APIWebhooksRefunds via APITest environmentForeign cards54-FZ receipts
Starting point
A team builds its own service with a user account area. Ready-made modules do not fit: plans, trial periods and invoicing live inside the product. They need payments created from their own backend, status notifications, refunds from the admin interface and a way to test the integration before going live with real money.
What was set up
The MulenPay REST API with webhooks, refunds through the API, a test environment and fiscal receipts (54-FZ) through a cloud online cash register. Payment methods for the service's users: Russian bank cards, SBP, SberPay, T-Pay and foreign cards.
How it works
The service backend creates a payment with an API request and sends the user to the payment page. It learns the result from a webhook rather than by polling: a signed notification arrives at the given address, and the service grants access right after confirmation. A refund is issued from its own admin panel with a separate request carrying the payment ID; the operation is refunded in full. While the integration is being written, requests go to the test environment. Method descriptions and request examples are published at docs.mulenpay.com, and support answers integration questions by email at support@mulenpay.com and in Telegram at @mulen_support_bot.
What changed
Payments live inside the product: access opens on a webhook, refunds are made from the team's own admin panel, receipts are generated without a separate cash-register integration. The team shipped payments without depending on someone else's interface and checked every flow in the test environment before launch.
Read more: Payment API

05

Services paid on the spot

Tools: QR code via SBPSBP54-FZ receiptsDashboard
Starting point
Delivery, a repair shop, a mobile service: payment is taken where the service is provided. Buying and maintaining a terminal was unwanted, cash is inconvenient, and transfers to an employee's card ended in arguments about who received how much. No receipt was issued at all.
What was set up
QR-code payment through SBP from the MulenPay dashboard: a static code for the location and a dynamic one for a specific order. Fiscal receipts (54-FZ) through a cloud online cash register, without buying one.
How it works
The static QR code is printed and stands at the counter or travels with the courier: the customer scans it with the camera, enters the amount and confirms the payment in their banking app. For an order with a known amount the employee creates a dynamic code in the dashboard with the amount already filled in. The money goes to the company account, not to the employee, and the status is visible in the dashboard right away. The limit per operation, as for other methods, is from 10 to 300,000 roubles.
What changed
On-site payment without a terminal and without cash. The money goes to the business account rather than an employee's personal card. The receipt is generated automatically. Every location and every employee is visible in one dashboard.
Read more: QR-code payments SBP payments

In common

What the scenarios share

The tools differ, the terms do not: they stay the same whichever setup path you choose

Setup in 1 day

An application, a check of the site or channel, a contract and integration keys. For ready-made modules and dashboard links that is enough to take the first payment.

Free integration

No setup fee and no monthly fee. Ready modules for 7 CMSs, guides for 14 platforms, the widget and the API are part of the terms; the fee is charged only on a completed payment.

Receipts automatically

A fiscal receipt under 54-FZ is generated through a cloud online cash register for every payment and every refund, in any of the scenarios.

One dashboard

Payments, refunds, links, QR codes and subscriptions in one place, whichever way payment is taken.

Questions and answers

Frequently asked questions

They are typical scenarios: this is how setup goes for a business of that kind. Company names and figures are not given; the tools and the order of steps are real.

Read next

Related pages

Pricing and fee calculator

Rates by payment method, limits and payout terms, the same for every scenario.

Fiscal receipts and 54-FZ

When a receipt is required and how a cloud online cash register generates it in each scenario.

Which scenario is yours?

Leave a request and a manager will pick the tools and terms for the way you sell.

Telegram bot

@mulen_support_bot

Quick answers 24/7

Contacts and departments

All contact channels

Six departments, response times and company details

Leave a request

Fill out the form — a manager will get in touch, tailor the terms and help with the integration.

By clicking the button you agree to the processing of personal data.

TelegramTelegram