Sofort and Klarna Pay Now
Sofort and Klarna Pay Now: What Merchants Need to Know About the Product and Brand Transition A merchant researching European bank payments can easily find three apparently interchangeable names: Sofort. SOFORT Banking. Klarna Pay Now. Which one should appear at checkout? Which o
Sofort and Klarna Pay Now: What Merchants Need to Know About the Product and Brand Transition
A merchant researching European bank payments can easily find three apparently interchangeable names:
Sofort. SOFORT Banking. Klarna Pay Now.
Which one should appear at checkout? Which one should the engineering team integrate? And if a customer still asks to “pay with Sofort,” does that mean the merchant needs a Sofort integration?
In 2026, those questions no longer have the same answer.
Klarna acquired SOFORT in 2014. A decade later, in July 2024, Klarna announced that Sofortüberweisung was being integrated into the Klarna environment and would form part of its Pay Now offering. Klarna's merchant migration guidance now points merchants from Bank Transfer via SOFORT toward Pay by bank via Klarna Payments.
Yet the Sofort name has not simply vanished. Klarna has continued using familiar Sofort terminology in markets with strong historical recognition, particularly Germany and Austria, while its current technical model is organized around Klarna Payments, Pay Now, and payment methods such as Direct Bank Transfer.
That distinction matters.
Search terminology can survive longer than a payment product's original merchant implementation.
For merchants, the correct question is therefore not whether “Sofort still exists” in the abstract. It is:
What live bank-payment capability sits behind the name the customer sees, and what does the merchant need to integrate and operate today?
What Sofort historically meant
Sofort—also widely known as Sofortüberweisung or SOFORT Banking—became known as an online bank-transfer method that allowed customers to initiate payment using their online banking access rather than entering card credentials.
Klarna acquired SOFORT in 2014.
For a merchant, the important historical characteristic was not the logo. It was the mechanic:
customer bank account → bank-authenticated transfer initiation → merchant payment
That distinguished the payment from Klarna's better-known pay-later and financing products.
This history explains why search results, old PSP documentation, checkout screenshots, merchant dashboards, integration notes, and customer-support material may still use “Sofort,” “SOFORT Banking,” “Sofortüberweisung,” and “Klarna Pay Now” in ways that appear interchangeable.
They should not be treated as interchangeable today.
How Sofort became part of Klarna
The first important date is 2014, when Klarna acquired SOFORT.
The more consequential merchant transition came a decade later.
On July 18, 2024, Klarna announced that Sofortüberweisung was being incorporated into the Klarna environment and made available within its Pay Now product range. Klarna said German consumers would continue seeing the Sofortüberweisung name while using the updated Klarna experience. The new flow also required a Klarna account.
Klarna's merchant migration material describes the corresponding transition as one from Bank Transfer via SOFORT toward Pay by bank via Klarna Payments. Merchants already integrated with Klarna Payments are instructed to activate Pay by Bank when it is available for their setup rather than create a new legacy SOFORT implementation.
That is the core product transition.
It is not simply:
Sofort → renamed Klarna Pay Now
The current model is more nuanced.
Pay Now is not the same thing as Sofort
This is the distinction merchants are most likely to miss.
Klarna's current merchant documentation groups payment methods into customer-facing categories. Under Pay now, its documentation currently lists:
DIRECT_DEBIT
DIRECT_BANK_TRANSFER
PAY_BY_CARD
So Pay Now describes when the customer pays, not necessarily how the money is funded.
That becomes particularly visible in Germany and Austria.
Klarna's current localized checkout guidance uses “Sofort bezahlen” as the German descriptor for the Pay Now category. Its accompanying description can tell customers that they may pay by Sofortüberweisung, direct debit, or card.
Therefore:
“Sofort bezahlen” ≠ necessarily “Sofortüberweisung.”
The first can now be a broader “pay now” presentation category. The second refers specifically to the bank-transfer heritage and mechanic.
That difference should shape everything from SEO copy to analytics tagging.
What exists today?
For merchant decision-making, four different concepts should be separated.
Sofort / SOFORT Banking
Treat this primarily as a historical merchant-product and search term.
Merchants may still encounter old integration documents, old URLs, screenshots, analytics labels, payment-method mappings, and customer references using the name.
It remains useful context.
It should not automatically be treated as the name of the integration a new merchant should build.
Sofortüberweisung
This term retains customer recognition, particularly in German-speaking markets, and Klarna has continued to use it in transition-related customer and merchant communication.
Its presence in customer-facing language does not prove that the merchant is running a historical SOFORT integration.
Klarna Pay Now / Pay now
This is the broader payment category.
A Pay Now experience can be funded through more than one mechanism. Current Klarna documentation identifies direct bank transfer, direct debit, and card among Pay Now methods.
Pay by Bank / Direct Bank Transfer
This is the bank-account-based payment capability merchants should investigate when their objective is to let customers pay from a bank account.
Klarna's migration guidance explicitly directs legacy SOFORT merchants toward Pay by bank via Klarna Payments.
That is the merchant-facing distinction that matters most.
The Sofort / Klarna Product Evolution Map
Term
What it historically/currently means
Owner/provider layer
Payment model
Merchant meaning in 2026
Integration direction
SOFORT / SOFORT Banking
Legacy product and brand terminology
SOFORT GmbH; part of Klarna since 2014
Bank-payment initiation
Primarily legacy integration/search terminology
Audit and migrate legacy dependencies
Sofortüberweisung
Familiar German-language bank-transfer terminology
Klarna environment today
Direct bank payment
May remain customer-facing terminology, especially during transition
Verify the live Klarna configuration behind it
Klarna Pay Now / Pay now
Pay-in-full category
Klarna
Category can include multiple funding methods
Do not assume it means bank transfer
Integrate Klarna Payments and inspect enabled payment options
DIRECT_BANK_TRANSFER / Pay by Bank
Current bank-payment capability terminology
Klarna payment/provider layer
Bank-account payment initiation
Relevant current capability where enabled for merchant and market
Klarna Payments / supported provider integration
“Sofort bezahlen”
German localized Pay Now descriptor
Klarna checkout presentation
Can represent several Pay Now funding choices
A label, not proof of a legacy Sofort transaction
Follow current Klarna presentation rules
Klarna's present documentation supports this separation: Direct Bank Transfer sits inside Pay Now rather than defining the entire Pay Now category.
Where is Sofort still relevant?
The answer depends on what “relevant” means.
Relevant to search and customer recognition
Yes.
A German or Austrian customer may still understand and search for Sofort or Sofortüberweisung, and Klarna has explicitly retained familiar Sofort terminology as part of its transition strategy in those markets.
Removing every reference to Sofort from merchant educational content could therefore make the content less useful.
Relevant as historical merchant documentation
Very much so.
Payments teams acquiring an older ecommerce stack may discover:
SOFORT credentials
old API references
historical PSP configurations
legacy payment-method IDs
old logos
Sofort-specific customer-service documentation
reporting rules built around the old settlement model
Those are migration signals.
Relevant as the name of a new standalone integration
That is where merchants should be cautious.
Klarna's own migration documentation directs merchants toward Pay by Bank within Klarna Payments. It also says Pay by Bank is delivered through the broader Klarna payment-services setup rather than being treated simply as the old standalone SOFORT product.
A new merchant should therefore verify the live product available through its provider or Klarna agreement instead of starting from an archived SOFORT implementation guide.
What should international merchants integrate today?
Start at the capability layer, not the brand-history layer.
A merchant looking for bank-account payments should determine whether its Klarna configuration returns and supports the appropriate direct-bank-transfer option for the relevant market and customer.
Klarna Payments sessions return available payment categories based on the merchant and transaction configuration. Klarna also requires merchants to have the relevant country enabled contractually; its documentation says an agreement or addendum is needed for each enabled purchase country.
That leads to an important implementation rule:
Do not infer Pay by Bank availability from the existence of Klarna in a country.
And do not infer it from the continued appearance of the word “Sofort.”
Instead verify:
Merchant
→ merchant entity
→ purchase country
→ currency
→ business model / MCC
→ Klarna agreement or payment provider
→ payment options returned for that session
Only then should the checkout decide what to display.
How the current customer journey works
The exact customer experience can vary by market, bank, device, customer state, and Klarna configuration.
At the Klarna level, the current standard flow begins when a customer selects Klarna and enters or logs into the Klarna experience. The customer can then select an available payment option.
For a Pay by Bank flow, current Klarna testing documentation illustrates a path that includes:
Customer chooses Klarna
→ Klarna account/identity step
→ Pay by Bank
→ bank selection
→ bank login or handoff
→ account selection where applicable
→ bank-side authorization
→ payment status returned through Klarna
→ merchant order processing
Klarna's current Pay by Bank testing flow specifically includes bank selection, bank authentication and an OTP-style authorization step in its demo environment.
On mobile, the handoff deserves particular attention. Klarna recommends its Mobile SDK for bank-transfer implementations and notes that a customer may be handed into a banking app and then returned to the merchant app.
This is where the historical phrase “online banking transfer” can be misleading. The modern experience may be driven by app-to-app bank authentication rather than a desktop-era redirect and credential form.
What actually moves the money?
Do not describe Klarna itself as a universal bank-payment rail.
Klarna provides the merchant-facing payment and initiation layer. The customer's bank executes the underlying account payment through infrastructure available in the relevant market.
That distinction matters because:
checkout confirmation
is not necessarily the same event as
bank authorization
which is not necessarily the same event as
funds received by the provider
which is not necessarily the same event as
merchant settlement.
For European electronic-payment initiation, PSD2's strong-customer-authentication regime requires payment service providers to apply SCA when the payer initiates an electronic payment transaction, subject to applicable rules and exemptions. The authentication itself belongs to the banking/payment-service environment rather than to the merchant.
The merchant controls the checkout integration.
The bank and payment-service layer control bank authentication and execution.
The merchant should not blur those responsibilities.
When does the merchant know the payment is real?
This question becomes especially important when comparing the old SOFORT operating model with newer Klarna products.
Klarna's migration material says legacy Bank Transfer via SOFORT left the settlement relationship between the consumer and merchant, whereas Pay by Bank through Klarna Payments brings the payment into Klarna's reconciliation and order-management model. For retail merchants, Klarna describes Pay by Bank through Klarna Payments as guaranteed; Klarna separately documents a non-guaranteed Pay by Bank model for certain specialist merchant segments.
That difference changes fulfillment logic.
In Klarna's current non-guaranteed Pay by Bank implementation, an order can initially have a payment status of UNPAID. A later webhook can move it to PAID when Klarna receives the money, or to CLOSED if payment is not received under the documented lifecycle.
That makes a general rule useful:
Never translate “customer finished the screen” into “merchant has an authoritative paid state” without checking the current product's status model.
For a guaranteed merchant configuration, the commercial guarantee and authorized-order state may support a different fulfillment policy.
For a non-guaranteed bank transfer, the merchant bears a different exposure.
The fulfillment event should therefore be documented per merchant configuration rather than copied from an old Sofort integration.
Integration model
A current direct Klarna Payments implementation typically involves three operational layers.
Payment session
The merchant creates a session through the Klarna Payments API and receives the customer-specific payment categories and client information needed to present Klarna.
Checkout and authorization
Klarna can be integrated through an inline experience or browser redirect. The customer enters the Klarna flow and completes the required payment-selection and authorization steps.
Order management
Once a purchase is created, post-purchase actions move into Klarna's Order Management capabilities, including capture and refund operations.
Merchants may also access Klarna through supported ecommerce or payment-provider integrations rather than integrating each API directly. Klarna's current documentation supports direct integrations as well as platform integrations.
The right choice depends on the merchant's existing payment architecture.
Reconciliation is one of the largest differences from old SOFORT
The transition is not only a branding change.
Klarna's own merchant migration material highlights a change in operating model: in its legacy description, SOFORT settlement occurred between the consumer and merchant; within Klarna Payments, Klarna says it receives the payment, performs reconciliation and provides order-management support before paying merchants on the configured payout schedule.
Current Klarna settlement reporting provides merchant reconciliation through the Merchant Portal, Settlements API, or SFTP. Settlement records have a payment reference that can also appear on the merchant's bank statement, providing a link between the Klarna settlement and the corresponding bank payout.
A sensible merchant data model is therefore:
Merchant order ID
→ Klarna session
→ Klarna order ID
→ authorization/payment state
→ capture
→ settlement transaction
→ Klarna payment reference
→ merchant bank payout
The merchant should preserve its own order reference throughout that chain. Klarna's Payments API provides merchant-reference fields, one of which is made available in settlement files.
That is considerably more useful than reconciling merely on amount and date.
Settlement does not mean instant merchant payout
A customer may complete a bank-funded payment quickly.
That does not mean the merchant receives funds in its bank account at the same moment.
Klarna's current settlement documentation distinguishes capture, the contractual payout schedule, creation of the settlement report, initiation of the payout, and eventual credit by the merchant's bank. Bank processing can affect when the payout actually appears.
So merchants should measure at least two separate times:
Payment-confirmation latency
and
Merchant-settlement latency
They answer different questions.
How refunds work
Merchants should also avoid importing legacy SOFORT refund assumptions into the current product.
Within the current Klarna order-management model, refunds can be initiated against captured orders using the Order Management API, and refunds can also be managed through the Merchant Portal. Klarna says a refund to a customer is reflected against the merchant's subsequent payout.
For the non-guaranteed Pay by Bank product, Klarna also explicitly lists refunds as part of the supported order-management lifecycle.
That does not justify the broader claim that every bank-payment refund in every Klarna market follows an identical path.
Before launch, merchants should test:
full-order refund behavior
partial-order refund behavior
refund status
refund reconciliation
customer communication
currency behavior
how the repayment appears to the customer
The current integration—not the historic Sofort name—should determine the operating procedure.
Can merchants use it for recurring payments?
This requires particularly careful language.
Klarna Payments as a broader platform supports recurring scenarios and tokenized payment use cases.
That is not sufficient evidence to claim that a merchant can universally reuse a Sofort/Pay by Bank bank account for recurring merchant-initiated charges in every market.
Before presenting bank transfer as a subscription method, verify:
whether Direct Bank Transfer is tokenizable for that merchant
whether the specific funding source can support subsequent charges
whether fresh customer authorization is required
country restrictions
provider implementation
fixed versus variable amounts
retry behavior
For this article, the correct conclusion is:
Recurring support is configuration- and funding-source-specific and should be verified rather than inferred from Klarna Payments' general recurring capabilities.
Is Pay by Bank the same thing as BNPL?
No.
This distinction is strategically important because Klarna is strongly associated with buy now, pay later.
Pay by Bank is a pay-in-full bank-funded method.
Klarna's current merchant documentation places Direct Bank Transfer under its Pay Now category, while Pay Later and Pay over time are separate categories.
A merchant writing “Klarna is BNPL” therefore obscures the bank-payment capability.
Likewise, writing “Sofort is now Klarna Pay Now” is too imprecise.
The useful model is:
Klarna = provider/platform
Pay Now = timing/category
Pay by Bank / Direct Bank Transfer = bank-payment mechanic
Sofort / Sofortüberweisung = historical and, in some markets, continuing customer-facing terminology
Is Pay by Bank open banking?
It can use open-banking connectivity and bank-authentication patterns, and Klarna itself describes the migrated experience as using open-banking standards.
But merchants should still avoid the shortcut:
Sofort = open banking = A2A = instant payment
Those terms describe different layers.
Open banking concerns access and payment initiation.
A2A describes account-to-account movement.
A bank-payment provider such as Klarna creates the merchant-facing initiation and operating layer.
The underlying bank infrastructure carries the actual transfer.
This distinction is covered more fully in Open Banking Payments and Account-to-Account Payments and should not be duplicated here.
Merchant availability: do not build a country list from memory
Klarna Payments currently supports multiple purchase countries and requires country-specific commercial enablement. Its documentation says merchants need an agreement or agreement addendum for each country they want to enable.
But Klarna being available in a country does not prove that Pay by Bank is available to every merchant there.
Product availability can depend on:
merchant entity
country
customer country
currency
business model
merchant category
provider
risk model
commercial agreement
integration
individual payment-session eligibility
That is why this article should not publish a permanent “Sofort countries” list and present it as current Klarna merchant coverage.
Klarna's transition documentation does specifically preserve Sofortüberweisung terminology for Germany and Austria, reflecting the brand's stronger history there.
Beyond clearly verified cases, merchants should query current provider documentation and their own live configuration.
Merchant eligibility also changed with the product model
Merchant access is not uniform.
Klarna's migration documentation differentiates standard retail merchants from certain regulated or specialist merchant categories. Current documentation also describes a Pay in Full – Non Guaranteed Pay by Bank product for restricted segments including gaming, gambling and crypto, with a different payment-status and settlement model.
That matters because two merchants showing similar customer language can have materially different risk and fulfillment rules.
Before launch, confirm:
Is the payment guaranteed or non-guaranteed?
When may the order be fulfilled?
Which webhooks are authoritative?
What happens if the bank transfer never arrives?
Who bears that loss?
Those are more consequential questions than whether the checkout button contains the word Sofort.
What merchants should do with legacy integrations
A legacy Sofort estate should be treated as a migration project, not merely a rebranding exercise.
Inventory what still depends on Sofort
Search:
code repositories
payment-method routing rules
PSP configurations
checkout labels
localization files
analytics dimensions
reconciliation jobs
customer-support macros
refund procedures
finance documentation
settlement reports
CMS content
SEO landing pages
knowledge-base articles
merchant contracts
Classify each occurrence
Every reference should be placed into one of four buckets:
Historical context
Keep when it helps readers understand what Sofort was.
Search-language bridge
Keep where people genuinely search for Sofort, but immediately translate it into the current product.
Customer-facing label
Use only if the live provider configuration and current branding guidance support it.
Technical dependency
Migrate or remove unless explicitly supported as part of the current integration.
That prevents a common failure: marketing updates its terminology while engineering, finance, or support continues operating against an obsolete assumption.
The same rule applies to SEO
A strong SEO page does not have to pretend the old product still exists unchanged.
In fact, the ambiguity is the search opportunity.
Searchers entering:
Sofort payments
accept Sofort
Sofort merchant
Sofort Klarna
Klarna Pay Now
Sofort online banking
are often trying to answer a current-state question.
The best page should say, immediately:
You are right to recognize Sofort. But the merchant product has evolved. Here is what that name maps to today.
That is more useful than either extreme:
Extreme 1: maintaining an obsolete “How to integrate Sofort” page.
Extreme 2: deleting Sofort from the site and forcing users to discover the transition themselves.
The correct strategy is a legacy-term bridge to current capability.
How merchants should measure the migration
Do not measure success from payment-method visibility alone.
Track the full current flow:
Eligible customer
→ Klarna visible
→ Klarna selected
→ Pay Now / Pay by Bank available
→ bank flow launched
→ bank authentication completed
→ payment reaches authoritative status
→ order completed
→ payment reconciled
→ refund completed where applicable
Useful measures include:
Bank-payment completion rate
Successfully completed eligible bank payments
÷ bank-payment flows initiated
× 100
Authentication completion rate
Customers completing the bank authentication stage
÷ customers reaching bank authentication
× 100
Authoritative-payment rate
Orders reaching the merchant's required paid/guaranteed state
÷ bank-payment orders created
× 100
Reconciliation exception rate
Bank/Klarna transactions requiring manual matching
÷ settled bank-payment transactions
× 100
Confirmation latency
Time between the defined customer authorization event and the payment state the merchant uses for fulfillment.
Incremental completed orders
Compare eligible customer cohorts with and without a usable bank-funded option.
The important question is not:
How many customers selected Sofort?
It is:
Did the current bank-payment capability create completed orders or better operational economics that would otherwise have been lost?
Testing before migration or launch
A transition should include end-to-end testing by market and device.
Test at minimum:
Desktop
first-time Klarna customer
returning customer
bank selection
customer cancellation
failed bank authentication
completed payment
expired payment
Mobile web
bank-app handoff
browser return
abandoned bank app
duplicate return
interrupted session
Native app
app-to-app bank authorization
deep-link return
background/foreground recovery
Operations
payment-state webhook
duplicate webhook
delayed notification
refund
settlement report
reconciliation
customer-support lookup
For non-guaranteed Pay by Bank configurations, test UNPAID, PAID, and CLOSED transitions specifically. Klarna documents those states for the current non-guaranteed implementation.
A payment method that produces strong selection but poor bank-authentication completion, unreliable mobile returns, or excessive reconciliation work may need a different checkout position or implementation.
Final recommendation
Sofort still matters.
But it matters differently than it once did.
It matters as a historically important bank-payment brand, as a term customers may recognize, as a source of old integrations that merchants still need to migrate, and as a search query that deserves a current answer.
It should not be used as evidence that an unchanged standalone Sofort merchant product is what a merchant should implement today.
For current implementation, merchants should identify the actual live capability behind their Klarna or PSP configuration—particularly Pay by Bank / Direct Bank Transfer—then verify its market availability, merchant eligibility, customer flow, payment-status model, refund process, reconciliation model and settlement terms.
The broader lesson extends beyond Sofort.
Payment names live in search engines, customer memory and old code long after payment products evolve.
Good payments operations separate those layers.
Good payments content should do the same.
Frequently Asked Questions
Does Sofort still exist?
The name still has customer and search relevance, and Klarna continues to use Sofortüberweisung terminology in parts of its transition and German-language experience. But merchants should not assume that this means the old standalone SOFORT merchant implementation remains the product they should build today. Klarna's merchant migration materials direct legacy bank-transfer merchants toward Pay by Bank through Klarna Payments.
Is Klarna Pay Now the same as Sofort?
No. Current Klarna documentation makes Pay Now a broader category. It can include Direct Bank Transfer, Direct Debit and Pay by Card.
What should merchants integrate instead of old Sofort?
Where available and commercially enabled, merchants looking for the bank-payment capability should evaluate Pay by Bank / Direct Bank Transfer through Klarna Payments or their supported payment provider. Availability must be verified for the individual merchant and market.
Will German customers still see the word Sofort?
They can. Klarna has deliberately retained familiar Sofort terminology in Germany, and its current German checkout descriptors still use “Sofort bezahlen.” But that label must not be interpreted as proof that the transaction necessarily uses the historic Sofort bank-transfer implementation.
Is Klarna Pay by Bank a BNPL payment?
No. Direct Bank Transfer belongs to Klarna's Pay Now category, distinct from its Pay Later and Pay over time categories.
Can Klarna bank payments be refunded?
Current Klarna Order Management supports refunds of captured orders, and Klarna's documented Pay by Bank migration/non-guaranteed models include refund support. The merchant should still verify exact refund behavior for its market and configuration.
Does the merchant receive its money immediately because the customer used a bank payment?
Not necessarily. Customer payment execution, provider confirmation and merchant payout are different stages. Klarna uses configured settlement schedules, generates settlement reporting, and initiates payouts that may subsequently take time to appear at the merchant's bank.
Can Pay by Bank be used for subscriptions?
Do not assume so. Klarna Payments supports recurring-payment scenarios generally, but merchants need specific confirmation that the bank-funded payment option available to them can be tokenized or reused for subsequent charges in the required country and configuration.
Merchant migration checklist
Before publishing, migrating or launching:
Identify every legacy Sofort dependency.
Determine whether it is content, checkout presentation, technical integration or operations.
Confirm the current merchant contract and enabled countries.
Confirm whether Direct Bank Transfer / Pay by Bank is actually returned for the intended customer.
Confirm the required customer-facing descriptor.
Confirm guaranteed versus non-guaranteed treatment.
Document the authoritative fulfillment state.
Validate bank-app and mobile return flows.
Test refund processing.
Test settlement reconciliation.
Remove obsolete SOFORT technical instructions.
Preserve useful Sofort SEO terminology only where the page immediately explains the current product.
Re-run the verification immediately before publication.
Editorial interpretation
The bank-payment decision this article owns is: whether a merchant encountering Sofort, SOFORT Banking, Klarna Pay Now, Pay by Bank, and Direct Bank Transfer should maintain, migrate, or build an integration—and what the merchant should actually call and operate today.
The customer who cannot adequately pay without this capability is: primarily a customer who wants to fund an ecommerce purchase directly from a bank account rather than rely on a card or credit product, particularly in European markets where the Sofort name retains recognition.
The payment rail or initiation layer is: bank-account payment initiation through Klarna's bank-connectivity/payment layer. It should not be presented as one universal underlying rail; the customer bank and market determine the actual bank-payment infrastructure involved.
The merchant-facing product is: today, principally Klarna Payments with Pay by Bank / Direct Bank Transfer where enabled—not a new standalone legacy SOFORT integration. Klarna's current technical documentation categorizes DIRECT_BANK_TRANSFER under Pay Now.
The unique evidence anchor is: payment-product names can retain substantial customer and search recognition after the merchant product behind those names has materially changed.
Editorial position: preserve “Sofort” where it helps customers and searchers understand the history, but do not preserve obsolete integration guidance merely because the old term still attracts traffic.
Common assumption challenged: “If customers still search for Sofort, Sofort must still exist in the same merchant form.”
Most important technical distinction: Pay Now is a payment category; bank transfer is a funding/payment mechanic. They are not synonyms.
Selected format: product-evolution and merchant-decision guide.
How this differs from adjacent bank-payment articles: this article does not own generic A2A, open banking, SEPA, or bank-transfer mechanics. It owns the translation between legacy Sofort terminology and current merchant implementation.
Unique evidence anchor
In July 2024, Klarna formally announced that Sofortüberweisung was being integrated into the Klarna environment and made part of its Pay Now product range. Klarna said German consumers would continue to encounter the familiar Sofortüberweisung terminology, even as the experience moved into Klarna.
Current documentation makes the terminology even more important for merchants. Klarna's Pay Now category can contain several payment methods: DIRECT_BANK_TRANSFER, DIRECT_DEBIT, and PAY_BY_CARD. In German-language checkout messaging, Klarna describes “Sofort bezahlen” as a category in which customers may pay by Sofortüberweisung, direct debit, or card.
That means a merchant can encounter all of these terms without them describing the same layer of the payment stack.
Editorial position
Use legacy terminology to explain the product's history. Use current product terminology to make merchant implementation decisions.
A merchant page may legitimately mention Sofort because customers still recognize and search for the term. But technical documentation, checkout configuration, operational procedures, integration work, and capability claims should be based on the currently contracted Klarna product rather than on historical SOFORT documentation.
Merchant decision
For a new implementation in 2026:
Do not begin by asking, “How do we integrate Sofort?”
Begin by asking:
Does our current Klarna or payment-provider configuration offer Pay by Bank / Direct Bank Transfer for this merchant, market, customer, and transaction type—and what customer-facing descriptor should be shown?
A legacy merchant should separately determine whether it still has old SOFORT configuration, reporting, content, credentials, redirects, or operational dependencies that need to be retired.
Structural rationale
The article moves from terminology to history, then from history to current capability. That order matters because the reader's problem is usually not understanding what a bank transfer is. It is determining which of several apparently related product names describes what they can actually offer today.
The architecture therefore follows the merchant's real decision sequence:
Recognize the naming problem.
Understand enough history to explain it.
Separate current product category from funding method.
Determine current merchant availability.
Map the customer journey.
Map integration and authoritative payment states.
Understand refunds, settlement, recurring limitations, and reconciliation.
Decide what to do with legacy integrations and SEO content.
Apply a current-state verification checklist before launch.
SEO metadata
Sofort and Klarna Pay Now: Merchant Guide (2026)
H1:
Sofort and Klarna Pay Now: What Merchants Need to Know About the Product and Brand Transition
Meta description:
Understand what happened to Sofort, how Klarna Pay Now and Pay by Bank differ, and what international merchants should integrate, operate and verify today.
URL slug:
/sofort-klarna-pay-now-merchants/
Sofort and Klarna Pay Now
Secondary keywords:
Sofort payments; Klarna Pay Now; Sofort Klarna; Sofort merchant; Klarna bank transfer payment; Sofort online banking; accept Sofort; Klarna Pay Now merchant
Related entities:
Sofortüberweisung; SOFORT Banking; Klarna Payments; Pay by Bank; Direct Bank Transfer; Pay Now; account-to-account payments; open banking; PSD2; strong customer authentication
Article excerpt:
Sofort remains familiar to European customers and searchers, but the merchant product behind the name has evolved. This guide separates legacy Sofort terminology from Klarna's current Pay Now and Pay by Bank capabilities so merchants can make the right integration and operating decisions.
Suggested structured data:
Article; BreadcrumbList; FAQPage only while the FAQ remains visible, current and compliant with the site's structured-data policy.
Suggested internal links:
Open Banking Payments — from the section explaining initiation versus the underlying payment infrastructure.
Account-to-Account Payments — from the Pay by Bank mechanic.
Bank Transfers as an Online Payment Method — from the historical Sofort explanation.
Europe Payment Guide — from the market-availability section.
Local Payment Methods — from the merchant portfolio/checkout discussion.
Supporting visual
Sofort / Klarna Product Evolution Map
Format: horizontal evolution diagram.
Stage 1 — Legacy Sofort
SOFORT / Sofortüberweisung
Bank-funded online payment
Legacy independent merchant integration
→
Stage 2 — Klarna ownership
Klarna acquires SOFORT in 2014
→
Stage 3 — Product integration
2024: Sofortüberweisung incorporated into the Klarna environment and Pay Now range
→
Stage 4 — Current merchant model
Klarna Payments
Pay Now category
↓
Direct Bank Transfer / Pay by Bank
Direct Debit
Card
→
Merchant decision
Preserve useful legacy terminology for customer/search understanding
but build against the current live capability
Callout:
“Pay Now describes when. Pay by Bank describes how.”
Image alt text:
Timeline showing Sofort evolving from the legacy SOFORT bank-transfer product into Klarna Payments, where Pay by Bank or Direct Bank Transfer is one funding method within the broader Pay Now category.
Author and human review
Proposed author:
Required reviewers:
European payments product specialist; merchant integration specialist; technical editor.
Optional reviewer if merchant eligibility or regulatory language is expanded:
Payments compliance specialist.
Do not attach names until the individuals have actually reviewed the article.
Recommended byline metadata:
Last reviewed: August 2026, updated again immediately before publication.
Authoritative source recommendations
Klarna — Sofort to Klarna Payments merchant migration page and FAQ. Primary source for the relationship between legacy Bank Transfer via SOFORT and Pay by Bank through Klarna Payments, including branding, migration, settlement and merchant-model distinctions.
Klarna — July 18, 2024 Sofort integration announcement. Primary source for the incorporation of Sofortüberweisung into the Klarna environment and Pay Now offering.
Klarna Docs — Payment methods availability. Primary technical source establishing that Direct Bank Transfer is a method within Pay Now rather than synonymous with Pay Now.
Klarna Docs — Localized Messaging for Checkout. Primary source for current customer-facing terminology by market, including “Sofort bezahlen” in Germany and Austria.
Klarna Docs — Klarna Payments API and integration documentation. Primary source for payment-session, authorization and integration mechanics.
Klarna Docs — Order Management and refunds. Primary source for post-purchase merchant operations.
Klarna Docs — Settlement reporting. Primary source for reconciliation and payout distinctions.
European Commission / European Banking Authority. Appropriate sources for PSD2/SCA statements rather than relying on merchant-provider marketing explanations.
Publication verification register
Rail / product fact-check items
Verified August 9, 2026
Klarna acquired SOFORT in 2014.
Klarna announced the integration of Sofortüberweisung into its environment in July 2024.
Current Klarna documentation places Direct Bank Transfer within Pay Now.
Pay Now can also contain direct debit and card.
Current migration documentation directs legacy SOFORT bank-transfer merchants toward Pay by Bank via Klarna Payments.
Recheck immediately before publication
Exact public branding of “Pay by Bank,” “Direct Bank Transfer,” “Pay Now,” and “Sofortüberweisung.”
Whether a new replacement product name has been introduced.
Whether any remaining SOFORT APIs or merchant portals have reached final end-of-support.
Country fact-check items
Recheck:
Countries where Pay by Bank is commercially available for standard retail merchants.
Countries where non-guaranteed Pay by Bank is available.
Whether Germany and Austria still retain Sofortüberweisung terminology.
Current UK and broader European availability.
Applicable currencies.
Bank coverage by country.
Do not publish an exhaustive country-availability table until these are confirmed against the live merchant/product configuration.
Merchant-eligibility fact-check items
Verify:
Merchant entity eligibility.
MCC/business-model restrictions.
Required Klarna agreement/addendum.
Local-entity requirements, if any.
Settlement-account requirements.
Retail guaranteed versus specialist non-guaranteed configuration.
Provider-specific merchant onboarding.
Minimum/maximum transaction values where material.
Confirmation and reconciliation fact-check items
Verify:
Authoritative payment state for the exact contracted product.
Which status permits fulfillment.
Webhook semantics.
Idempotency requirements.
Guaranteed versus non-guaranteed treatment.
Order/capture relationship.
Merchant references included in settlement records.
Settlement-report format and cadence.
Refund and recurring fact-check items
Verify:
Full refund.
Partial refund.
Refund funding path.
Refund timing.
Refund currency.
Customer-account requirements.
Whether Direct Bank Transfer itself supports tokenization.
Whether subsequent merchant-initiated bank charges are permitted.
Variable/fixed recurring amounts.
Market-specific recurring restrictions.
Regulatory fact-check items
Verify immediately before publication if regulatory discussion is expanded:
Current PSD2/PSD3/Payment Services Regulation status in the jurisdiction.
Applicable SCA rules.
Klarna entity providing the relevant regulated payment service.
Any local consumer-protection requirements.
Requirements for payment initiation or bank-data access.
Disclaimer:
This article provides general information and does not constitute legal, regulatory, banking, tax, security or compliance advice. Merchants should verify applicable requirements with qualified advisers, relevant payment providers, banks, scheme operators and authorities.
Amber-flag claims
The following claims should not be added without refreshed, directly applicable evidence:
“Sofort has been completely discontinued everywhere.”
“Sofort was simply renamed Klarna Pay Now.”
“Klarna Pay Now means bank transfer.”
“Pay by Bank is available in every Klarna market.”
“All Pay by Bank transactions are guaranteed.”
“All Pay by Bank transactions are instant.”
“The merchant receives funds instantly.”
“Bank transfers are irreversible.”
“Sofort/Klarna Pay by Bank is chargeback-free.”
“All refunds automatically return over the same bank rail.”
“Pay by Bank supports subscriptions.”
“Sofort increases conversion.”
“Bank payment is cheaper than card payment.”
Any bank-count, acceptance-rate or conversion-uplift statistic from provider marketing without defining the cohort and applicability.
Klarna currently publishes marketing statistics about bank connectivity and transition performance, but those should not be generalized into merchant promises without the underlying methodology and target-population match.
Countries where it can be activated.
Merchant vertical restrictions.
Direct versus partner/provider implementation.
Guaranteed/non-guaranteed model.
Payment-status mapping.
Refund capability.
Settlement model.
Settlement currencies.
Reconciliation fields.
Mobile-bank redirect support.
Recurring capability.
Merchant onboarding requirements.
Provider-specific verification requirements
For Klarna or any PSP distributing Klarna, verify:
Current product name exposed to the merchant.
Current customer-facing descriptor.
Current API method/category identifier.
Country availability.
Merchant category eligibility.
Bank coverage.
Integration option.
Required Klarna account behavior.
App-to-app flow.
Guaranteed versus non-guaranteed payment.
Authoritative fulfillment state.
Order/capture requirements.
Refund support.
Settlement schedule.
Reconciliation format.
Dispute handling.
Recurring funding-source support.
Do not assume a PSP's legacy sofort method code maps one-to-one to Klarna's present DIRECT_BANK_TRANSFER.
Cluster sameness-audit fields
Title:
Sofort and Klarna Pay Now: What Merchants Need to Know About the Product and Brand Transition
First two sentences:
“A merchant researching European bank payments can easily find three apparently interchangeable names: Sofort. SOFORT Banking. Klarna Pay Now. Which one should appear at checkout?”
Opening device:
Three conflicting product names.
Primary region:
Europe, led by Germany/Austria legacy recognition.
Payment rail:
Market-dependent bank-transfer infrastructure; no single underlying rail is claimed.
Merchant-facing method:
Klarna Pay by Bank / Direct Bank Transfer within Klarna Payments.
Primary format:
Product-evolution and merchant-decision guide.
Unique evidence anchor:
Search recognition can outlive a payment product's original merchant implementation.
Editorial position:
Retain legacy terminology for explanation/search intent, not as obsolete implementation guidance.
Merchant decision:
Verify and integrate current Pay by Bank/Direct Bank Transfer capability rather than starting a new legacy Sofort implementation.
Original framework:
Sofort / Klarna Product Evolution Map.
Primary metric:
Authoritative bank-payment completion rate, supported by authentication completion and reconciliation exception rate.
Conclusion:
Product names can persist longer than payment implementations; merchant operations must follow the current capability.
CTA:
Audit the merchant's current live bank-payment configuration and legacy Sofort dependencies before changing checkout or content.
Closing element:
Brand/current-status FAQ plus migration checklist.
Final editorial recommendation
Publish this as a current-state explainer, not a traditional payment-method profile.
The strongest SEO and merchant value comes from answering the ambiguity that existing search results create:
Sofort is still a useful word. It is no longer sufficient implementation guidance.
That gives this article a genuinely distinct place within the Bank-Based Payments cluster. The generic bank-transfer article explains what an online bank transfer is. The open-banking article explains the initiation model. The A2A article explains the funding model.
This article explains what a merchant should do when the payment product's historical name, customer-facing label and current technical implementation no longer line up neatly.
Need help narrowing down payment options?
Answer a few questions about your business and compare the capabilities that matter to you.
Explore matching options ↗