Magento · Adobe Commerce
A payment module is a deployment, not a download
Magento stores are built and run by developers, and payments are part of that code. Adding a provider means a module installed through staging, configured per website, and tested against the way your store captures, refunds and processes orders at scale.
# on staging, never straight to production$ composer require vendor/payment-module$ bin/magento module:enable Vendor_PaymentModule$ bin/magento setup:upgrade$ bin/magento setup:di:compile$ bin/magento setup:static-content:deploy$ bin/magento cache:flush✓ module enabled · configure keys per website→ test payments, refunds and notices on staging
Gate before production: test orders pass · refunds sync · notices reach the store · rollback plan ready
Authorize, capture, and methods that don't fit either
Magento lets a payment method either authorize only (reserve the amount) or authorize and capture together (take it). Stores that ship later sometimes authorize at checkout and capture on shipment, so customers aren't charged for what's out of stock.
In India that model applies mainly to cards. UPI, net banking and most other methods take the money immediately, with no separate capture step. A store mixing methods needs one fulfilment process that handles both: captures for card authorizations, refunds for everything else.
| Action | What happens | Watch for |
|---|---|---|
| Authorize | Amount reserved on the card | Authorizations expire; capture before they do |
| Authorize and capture | Amount taken at checkout | Cancelled orders need refunds, not voids |
| Capture later | Taken when the invoice is created | Partial shipments may need partial captures |
| Immediate methods (UPI and others) | Money taken at payment | No capture step; use refunds for changes |
Websites, store views and currencies
One Magento installation often runs several brands, countries or languages. Its configuration scopes (global, website, store view) let payment settings differ between them: a different provider account per brand, different methods per country, different currencies. Map your structure before configuring anything.
Per website
Separate provider accounts for separate brands, so settlements and reports stay separate.
Per store view
Titles and instructions in each language; method order by market.
Per currency
Only methods that support a currency should appear for it; check with the provider.
Which scopes a module actually supports depends on how it's built. Check before planning around it.
Notices, cron and stuck orders
Magento relies on scheduled jobs (cron) for a lot of background work, and many payment modules use it to check pending payments or cancel abandoned ones. If cron stops, orders stop updating, often silently.
Treat the provider's notice URL and cron as part of the payment system. Monitor both, and alert when pending orders pile up past a normal level.
Notice URL reachable
Not blocked by a firewall, WAF rule or full-page cache.
Cron running
Checked by monitoring, not by noticing stuck orders.
Pending-order alert
A count of orders pending longer than usual.
Reconciliation
Provider settlement reports matched to Magento invoices daily.
Refunds through credit memos
In Magento, a refund starts as a credit memo against an invoice. A module that supports online refunds sends the refund to the provider when the credit memo is created from the invoice; an offline credit memo only records it in Magento, and the money has to be returned separately in the provider's dashboard.
Mixing the two is how refunds go missing: the store shows the order refunded, the customer never got the money. Train whoever issues refunds on which one to use for each payment method, and reconcile credit memos against the provider's refund report.
| Online credit memo | Offline credit memo | |
|---|---|---|
| Money returned by | The module, through the provider | Someone, separately |
| Needs | An invoice captured through the module | Nothing from the provider |
| Risk | Module or provider errors | Refund recorded but never sent |
| Use for | Payments taken through the module | Cash, bank transfers, or where online isn't supported |
B2B stores: payment isn't always at checkout
Many Magento installations serve business buyers, who often don't pay by card at the moment of ordering. They order on credit terms, against a purchase order, or pay by bank transfer after an invoice. The online payment module is then one of several ways an order gets paid, and collecting the others is a separate job.
Purchase orders
Order now, invoice later; payment follows the buyer's approval process.
Credit terms
Pay within an agreed number of days; collections need references to match.
Online payment
Card or UPI at checkout for smaller or new buyers.
Collecting on invoices: virtual accounts and payment links.
Headless storefronts and custom checkouts
Some Magento stores run a separate front end (a PWA or another framework) and use Magento only behind the scenes. A payment module built for Magento's own checkout may not work there without extra work, because the payment step now lives in code the module doesn't control.
If your storefront is headless, ask the provider specifically how its payment step works with your front end, and budget development time for it.
Checkout on Magento's own pages. Modules usually work as designed.
Headless front end. The provider's front-end SDK or hosted page, wired in by your developers.
Third-party one-page checkouts. Check compatibility with the payment module explicitly.
Protecting the checkout from skimming
Large Magento stores are a known target for attacks that inject code into the checkout to copy what customers type. The defences are mostly about controlling what runs on checkout pages, and keeping card entry off them where possible.
Provider-hosted payment pages or fields keep card details away from your own code. Beyond that: apply Adobe's security patches promptly, limit who can change the site, review third-party scripts on checkout, and monitor for unexpected changes to checkout files.
| Measure | Protects against |
|---|---|
| Provider-hosted card entry | Card details passing through your pages |
| Security patches on time | Known vulnerabilities being exploited |
| Few third-party scripts on checkout | A compromised script reading the page |
| File-change monitoring | Injected code going unnoticed |
| Admin access control | Stolen admin logins used to alter checkout |
Large orders and fraud checks
High-value orders attract fraud, particularly for electronics and other goods that resell easily. Providers run their own checks, and card payments carry the issuer's authentication, but it's worth adding your own rules for orders that look unusual: new customers ordering several expensive items, shipping and billing details that don't match, or many attempts with different cards.
Decide what happens to a flagged order (a hold, a call to the customer, or a switch to a slower payment method) before sale day, not during it. Link fraud rules to the same order record your team uses, so a held order doesn't ship by mistake.
Getting ready for sale days
Large stores do much of their year in a few sale events, and payments are where a sale-day failure costs most. Load-test checkout, including the payment step against the provider's test environment, well before the event, and agree with the provider what traffic to expect.
Freeze changes. No module or configuration changes in the days before a sale.
Tell the provider. Expected peak and timing, so there are no surprises on either side.
Have a fallback. A second enabled method or provider if one degrades.
Watch live. Success rate by method, pending counts, and notice failures during the event.
Questions for a payment module
- 01Which Magento and Adobe Commerce versions is it tested with, and how fast does it support new ones?
- 02Is it installed through Composer, and where is the code published?
- 03Which payment actions does it support: authorize, capture later, partial capture?
- 04Does it support website and store-view scopes, and multiple currencies?
- 05How does it receive notices, and does it depend on cron?
- 06Do refunds from a Magento credit memo reach the provider?
Patching matters too: keep Magento on Adobe's security releases, applied through staging. Saved cards in India work only through tokens; see card tokenisation.
Where Peneu fits
This page doesn't say a Peneu extension for Magento or Adobe Commerce exists or is listed on any marketplace, and no store size, volume or customer count is claimed. Whether Peneu can be used with a Magento store, and how, is confirmed during onboarding.
Magento payment questions
How is a payment module installed on Magento?
Usually with Composer, then enabling the module and running Magento's setup and compile steps, first on a staging copy and then on production in a planned deployment. Follow the module's own instructions and Adobe's documentation for your version.
What's the difference between 'authorize' and 'authorize and capture'?
Authorize only reserves the amount on the customer's card; capture actually takes it, often when the order ships. Authorize and capture does both at once. Which fits depends on your fulfilment, and on what the provider and payment method support: UPI and many other methods don't have a separate capture step.
Can different websites or store views use different payment settings?
Magento's configuration scopes let settings differ by website or store view, such as different provider accounts per brand or country. Whether a module supports that depends on how it's built; check before assuming.
Why do Magento orders stay in 'pending payment'?
Most often the provider's notice isn't reaching the store, or the job that processes it isn't running. Check the provider's record of failed notices, your web server's logs, and that Magento's cron is running.
How often should a Magento store be patched?
Whenever Adobe releases security patches for your version, applied through staging. A checkout that handles payments is exactly what attackers look for on outdated stores.
Is Magento Open Source different from Adobe Commerce for payments?
Both use the same payment module structure, so most modules support both. Adobe Commerce adds features such as B2B tools and is licensed and supported differently. Check that a module states support for your edition and version.
Why was a refund recorded but never received?
Usually because an offline credit memo was created: it records the refund in Magento without sending it to the provider. Refund online from the invoice where the module supports it, or return the money in the provider's dashboard.
Should the payment module be tested on every Magento upgrade?
Yes. Upgrades change the checkout and the code modules rely on. Run the full payment test set on staging after every Magento upgrade and every module update, before production.
Can one Magento store use two payment providers?
Yes, many large stores do, for example one provider per method or a second as a fallback during sale events. Each module needs its own configuration, testing and reconciliation, and your team needs to know which provider handled each order.
Does Peneu have a Magento extension?
This page doesn't say a Peneu extension exists or is listed on any marketplace. Whether Peneu can be used with a Magento or Adobe Commerce store, and how, is confirmed during onboarding.
Last reviewed . Examples, amounts and screens marked illustrative are not Peneu figures.