Digital Payments, Trust and Cybersecurity

Introduction and Context

Digital entrepreneurship depends on the ability to convert customer intention into a safe, convenient, and completed transaction. A digital product may attract visitors through social media, search, or marketplaces, but the venture creates economic value only when customers can pay and the entrepreneur can receive funds reliably. Payment systems therefore constitute more than a technical feature. They are part of the venture’s value proposition, operating model, risk profile, regulatory obligations, and relationship with customers.

A customer deciding whether to pay online is making a trust judgment. The customer asks, often implicitly: Is this business genuine? Will the payment be processed correctly? Will personal and financial information be protected? Can the transaction be reversed if something goes wrong? Entrepreneurs must answer these questions through system design, transparent communication, effective customer service, and responsible cybersecurity.

This chapter examines payment gateways, digital wallets, cards, bank transfers, embedded finance, fraud controls, and chargebacks. It then develops the principles of privacy-by-design, authentication, encryption, security risk management, and incident response. The emphasis is practical: an entrepreneur should be able to select a payment architecture, identify risks, evaluate controls, and respond competently when a security or payment dispute occurs.

Learning Objectives

By the end of this chapter, students should be able to:

1. Explain how major digital payment instruments and payment intermediaries operate.
2. Compare gateways, payment service providers, wallets, cards, bank transfers, and embedded finance.
3. Analyse payment costs, fraud exposure, settlement risk, and customer experience.
4. Distinguish authentication, authorization, encryption, tokenization, and non-repudiation.
5. Apply privacy-by-design and security risk-management principles to an entrepreneurial venture.
6. Explain chargebacks, disputes, fraud controls, and evidence requirements.
7. Construct a basic incident-response plan and evaluate ethical and regulatory responsibilities.

1. The Digital Payment Ecosystem

A digital payment normally involves several parties:

• Payer or cardholder: the customer initiating payment.
• Merchant: the business supplying goods or services.
• Payment gateway: the technical interface that securely collects and transmits payment information.
• Payment processor or payment service provider (PSP): the organization that routes transactions, applies controls, and connects merchants to payment networks.
• Acquirer: the financial institution or acquiring service that receives card transactions on behalf of the merchant.
• Issuer: the bank or institution that issued the customer’s card or account.
• Payment network: a network that routes and governs transactions between issuers and acquirers.
• Regulator and standards bodies: authorities and organizations establishing requirements for consumer protection, privacy, anti-money-laundering controls, and payment security.

A simplified card transaction has two stages. During authorization, the issuer decides whether the transaction may proceed, considering account status, available funds or credit, and risk signals. During clearing and settlement, transaction records are reconciled and funds are transferred, usually subject to fees, reserves, currency conversion, and settlement timing.

The entrepreneur should distinguish the customer-facing payment experience from the underlying money movement. A “successful” screen may mean that authorization has been approved, not that the merchant has irrevocably received money. Refunds, reversals, delayed settlement, disputes, and compliance reviews may occur later.

2. Payment Methods and Business Models

2.1 Payment gateways and payment service providers

A gateway connects a merchant’s checkout to payment infrastructure. It may host a payment page, provide application programming interfaces (APIs), tokenize sensitive information, return transaction results, and support refunds. A PSP may provide the gateway together with acquiring, fraud management, reporting, foreign-exchange services, and merchant onboarding.

There are two broad integration approaches. In a hosted checkout, the customer is redirected to or presented with a payment page operated by the provider. This can reduce the entrepreneur’s exposure to payment-card data and simplify compliance. In a direct API integration, the merchant controls more of the user experience but assumes greater responsibility for secure software development, data handling, authentication, logging, and regulatory compliance.

Selection criteria include:

• supported payment methods and currencies;
• geographic coverage and settlement availability;
• transaction and platform fees;
• refund and dispute functions;
• fraud tools and quality of risk data;
• uptime, technical documentation, and support;
• reconciliation and reporting capabilities;
• data location, privacy terms, and subcontractors;
• onboarding requirements and reserve policies.

A low headline fee may be misleading if the provider has high cross-border charges, minimum monthly fees, delayed settlement, expensive disputes, or poor support. Total cost of payment should be assessed over the complete transaction life cycle.

2.2 Cards

Credit and debit cards remain important for online commerce. Cards offer familiarity, broad acceptance, and established dispute processes. They also create risks: stolen card details, card-not-present fraud, account takeover, friendly fraud, and chargebacks.

Card security controls may include address or postal-code checks, device and behavioural signals, transaction limits, velocity rules, and strong customer authentication where applicable. Entrepreneurs should not collect or store raw card numbers unless there is a compelling reason and the organization can meet the associated security obligations. Hosted forms and tokens are generally safer. A token is a substitute value that refers to a payment credential without exposing the original credential to ordinary merchant systems.

2.3 Digital wallets

A digital wallet stores payment credentials or account value and permits payment through a mobile application, browser, device, or wallet account. Examples include device-based wallets, account-based wallets, and stored-value wallets. Wallets can improve conversion because customers may not need to re-enter card details. They can also support biometric or device authentication.

However, a wallet shifts some risks rather than eliminating them. A compromised email address, mobile device, recovery process, or wallet account may permit unauthorized payment. Entrepreneurs should therefore monitor wallet-specific disputes, verify webhook events, and avoid treating a client-side success message as proof of payment.

2.4 Bank transfers and account-to-account payments

Bank transfers may be cheaper than cards and can be useful for high-value or business-to-business transactions. They may involve real-time payment systems, scheduled transfers, open-banking interfaces, or manual bank instructions. Their disadvantages can include slower confirmation, irrevocable or difficult-to-reverse transfers, reconciliation complexity, and exposure to social engineering.

A merchant should reconcile incoming funds against a trusted bank or PSP record rather than relying only on customer-uploaded receipts. For high-risk transactions, payment confirmation should be linked to the exact order, amount, currency, and beneficiary account.

2.5 Embedded finance

Embedded finance integrates financial services into a non-financial digital platform. Examples include a marketplace offering seller payouts, an application offering working-capital finance, a platform providing insurance at checkout, or a software service embedding accounts and payment acceptance.

Embedded finance can increase convenience and create new revenue streams, but it also expands the venture’s responsibilities. The entrepreneur may become dependent on regulated partners, manage customer funds, conduct identity verification, monitor suspicious activity, and handle complaints. A platform must define clearly which entity is responsible for safeguarding funds, executing payments, resolving disputes, and complying with applicable law. The presence of a banking or payment partner does not automatically remove the platform’s operational and reputational responsibility.

3. Economics of Digital Payments

Payment economics include explicit and indirect costs. Explicit costs may include a percentage fee, a fixed transaction fee, currency conversion charges, refunds, and dispute fees. Indirect costs include fraud losses, operational labour, delayed cash flow, customer abandonment, and the cost of security controls.

A simple transaction-fee model is:

Here, F is the payment fee in currency units, r is the percentage fee expressed as a decimal, P is the transaction amount, and f is the fixed fee. The model assumes one provider, one transaction, and no additional taxes, currency conversion, reserve, refund, or dispute charges.

For example, with a transaction of 80 currency units, a rate of 2.5% and a fixed fee of 0.30:

The merchant receives 77.70 before other deductions. For small transactions, the fixed fee forms a larger proportion of revenue. Entrepreneurs should therefore consider minimum order values, bundles, alternative payment methods, and pricing that remains transparent and lawful.

A broader expected-loss model can support risk decisions:

EL is expected loss per transaction or period; p_f, p_d, and p_o are the probabilities of fraud loss, dispute loss, and other operational loss; and L_f, L_d, and L_o are the corresponding loss amounts. The terms should be estimated over a defined population and time period. This is an expected-value model, not a prediction that every period will experience the average loss.

Security controls should be evaluated against both loss reduction and business friction. A control that blocks many legitimate customers may reduce fraud while damaging conversion. The relevant decision is not simply “maximum security,” but an appropriate balance among assurance, accessibility, cost, privacy, and customer experience.

4. Trust, Authentication, and Transaction Security

Trust in e-commerce has technical, institutional, and relational dimensions. Technical trust depends on secure infrastructure and accurate transaction processing. Institutional trust depends on recognized payment providers, regulation, dispute mechanisms, and credible identity. Relational trust depends on honest pricing, clear policies, responsive support, and fulfilment performance.

Authentication, authorization, and accounting

These terms must be distinguished:

• Authentication: establishing who a user or system is.
• Authorization: deciding what an authenticated actor may do.
• Accounting or auditability: recording what happened, when, and through which account or device.
• Non-repudiation: creating evidence that supports attribution of an action, although no technical mechanism can eliminate every legal or operational dispute.

Strong authentication combines independent factor categories, such as knowledge, possession, and inherence. A password and a second code sent to the same compromised email account may provide less independence than a password combined with a hardware security key or authenticator application. Biometrics are generally better understood as a way to unlock a device or credential than as a secret that can simply be replaced if exposed.

For merchants, privileged administrator accounts require especially strong controls: multifactor authentication, separate administrator identities, least privilege, approval for sensitive actions, and logging. Payment refunds, payout-account changes, discount creation, and export of customer data should not be available to every employee.

Encryption and tokenization

Encryption transforms readable data into ciphertext using an algorithm and key. It protects confidentiality when correctly implemented and when keys are managed securely. Encryption in transit protects communications between systems; encryption at rest protects stored data. Encryption does not by itself guarantee that the recipient is legitimate, that the endpoint is secure, or that an authorized user will not misuse decrypted data.

Hashing is a one-way transformation commonly used for integrity checks and password storage. Passwords should be stored using a password-specific, salted, adaptive hashing method rather than reversible encryption or unsalted general-purpose hashes.

Tokenization replaces sensitive payment data with a token. The token may be useful only within a defined provider environment. Tokenization can reduce the scope and impact of a merchant breach, but it does not remove the need to secure accounts, APIs, logs, browsers, and provider integrations.

Secure software and payment messaging

Payment applications should validate server-side, not merely in the browser. They should protect secrets, verify webhook signatures, prevent replay of events, use unique transaction identifiers, and implement idempotency. Idempotency means that repeating the same request, such as a network-retried payment request, does not unintentionally create multiple charges.

Logs should record transaction identifiers, outcomes, timestamps, and relevant security events without storing unnecessary card data, passwords, authentication codes, or complete personal information. Monitoring should detect unusual refund rates, repeated failed logins, rapid card testing, unusual payout changes, and abnormal administrator activity.

5. Fraud Controls and Chargebacks

Fraud controls should be layered. No single rule reliably distinguishes all legitimate and fraudulent transactions. A risk engine may combine transaction amount, account age, device reputation, IP or network signals, shipping information, velocity, historical behaviour, authentication results, and known compromised credentials.

Common controls include:

1. Preventive controls: strong authentication, secure checkout, rate limits, bot protection, and least-privilege access.
2. Detective controls: monitoring, anomaly detection, reconciliation, and alerting.
3. Responsive controls: account suspension, refund review, credential reset, investigation, and incident response.
4. Corrective controls: patching, customer notification, process redesign, and staff training.

Rules must be tested for false positives and unfair effects. Blocking a transaction because of a broad geographic assumption may disadvantage legitimate customers. Automated decisions should have review pathways, clear customer communication, and human oversight for consequential outcomes.

A chargeback is a payment reversal initiated through a card issuer or payment network after a cardholder disputes a transaction. Reasons may include unauthorized use, non-receipt, defective goods, duplicate processing, or misleading transaction descriptions. A customer complaint and a chargeback are not identical: a merchant can often resolve a complaint directly before it becomes a formal network dispute.

A chargeback process commonly includes notification, a response deadline, submission of evidence, issuer or network review, and a final decision or escalation. Useful evidence may include order records, delivery confirmation, customer communications, terms accepted at checkout, device or authentication information, refund records, and a clear description appearing on the customer’s statement. Evidence must be relevant and privacy-conscious; sending excessive personal data can create a new risk.

Entrepreneurs should track the chargeback rate, reason codes, recovery rate, time to respond, and recurring root causes. Prevention is usually better than aggressive representment. Accurate product descriptions, recognizable billing descriptors, visible cancellation procedures, delivery tracking, and prompt customer support reduce disputes.

6. Privacy-by-Design

Privacy-by-design treats privacy as a system property established during planning rather than an afterthought. The approach is consistent with principles found in major privacy frameworks, although exact legal duties vary by jurisdiction.

Core practices include:

• Data minimization: collect only information needed for a defined purpose.
• Purpose limitation: do not quietly reuse payment or identity data for unrelated objectives.
• Transparency: explain what is collected, why, with whom it is shared, and how long it is retained.
• User control: provide appropriate access, correction, deletion, objection, or portability mechanisms where required.
• Security by default: configure systems so that the least amount of data is exposed.
• Retention limitation: delete or anonymize information when it is no longer needed, subject to legal and accounting obligations.
• Accountability: document decisions, suppliers, assessments, controls, and incidents.

Privacy is not equivalent to secrecy. A business may need identity and transaction records for fraud prevention, taxation, accounting, or legal compliance. The entrepreneurial task is to justify the collection, protect it, limit access, and communicate honestly.

A privacy impact assessment is useful when introducing behavioural profiling, biometrics, location data, large-scale monitoring, or a new payment partner. It should identify data flows, purposes, risks to individuals, mitigation measures, retention periods, and responsible owners.

7. Security Risk Management

Cybersecurity risk management is a continuous process of identifying assets, threats, vulnerabilities, impacts, and controls. Important assets include customer accounts, payment credentials or tokens, order databases, source code, cloud environments, staff identities, payout accounts, and business reputation.

A practical risk register can use the following fields:

A common qualitative model uses a likelihood-impact matrix. It is not a universal law and should not be confused with a precise probability calculation. If numerical scoring is used, the organization must define scales consistently. A high-impact, moderate-likelihood risk may deserve priority even when a low-impact risk is more frequent.

Risk treatment may involve avoiding a feature, reducing exposure through a hosted payment page, transferring some operational responsibility through a contract, or accepting residual risk with documented approval. Outsourcing payment processing does not outsource governance. Contracts should address security obligations, breach notification, audit rights, data processing, availability, subcontractors, termination, and data return or deletion.

8. Incident Response and Business Continuity

An incident is a suspected or confirmed event that threatens confidentiality, integrity, or availability. Examples include stolen administrator credentials, malicious code on a checkout page, unauthorized payout changes, ransomware, exposed customer data, or a provider outage.

An effective incident-response lifecycle includes:

1. Preparation: define roles, contact lists, backups, logging, exercises, and decision authority.
2. Detection and analysis: validate alerts, determine scope, preserve evidence, and classify severity.
3. Containment: limit spread, disable compromised accounts or keys, isolate systems, and protect funds.
4. Eradication: remove malicious access, patch vulnerabilities, rotate secrets, and eliminate persistence.
5. Recovery: restore trusted systems, test carefully, monitor for recurrence, and reconcile transactions.
6. Lessons learned: identify root causes, improve controls, document decisions, and update training.

During an incident, speed matters but uncontrolled action can destroy evidence or worsen the situation. The organization should maintain an incident log, record timestamps in a consistent time zone, preserve relevant system records, and involve legal, privacy, payment, and communications specialists when appropriate. Notification duties depend on jurisdiction, data type, contractual terms, and the nature of the incident; they should not be improvised.

Business continuity planning should address payment-provider outage, cloud failure, unavailable staff, communication disruption, and inability to access order records. Recovery objectives should be realistic. A small venture may prioritize restoring checkout, customer support, fulfilment records, and payout visibility in that order, while using a clearly communicated temporary alternative.

9. Illustrative Case: GreenBasket Marketplace

Background

GreenBasket is a fictional online marketplace connecting consumers with small organic-food producers. It accepts cards and wallets and pays sellers weekly. Growth has increased transaction volume, but the venture has only two technical employees.

Problem

GreenBasket experiences repeated card-testing attacks: automated actors attempt many low-value transactions using stolen card numbers. Legitimate customers encounter declines, support requests increase, and the payment provider threatens higher reserves. In addition, sellers receive fraudulent emails requesting that their payout bank accounts be changed.

Analysis

The venture identifies two related but distinct risks. First, checkout is being abused to test payment credentials. Second, seller accounts are vulnerable to social engineering and account takeover. The existing system trusts browser-submitted payment results, lacks consistent multifactor authentication for sellers, and allows payout changes without independent verification.

Approach and solution

GreenBasket moves card-data collection to a hosted provider form and uses provider tokens. It adds rate limits, device and velocity monitoring, and a modest risk-based review for unusual patterns. It verifies payment status through signed server-to-server events and uses idempotency keys to prevent duplicate charges.

For seller security, it introduces multifactor authentication, least-privilege administration, a cooling-off period for payout-account changes, and confirmation through a previously registered channel. Staff are trained never to approve a payout change solely from an email request. The company creates a chargeback evidence process and makes its billing descriptor and cancellation terms clearer.

The venture also creates an incident playbook covering credential reset, payment-provider escalation, seller notification, evidence preservation, and regulatory assessment. It reviews the provider contract and documents which party handles card-data security, disputes, and incident notification.

Outcome

The controls reduce automated attempts and improve the quality of legitimate approvals. Some legitimate transactions are still referred for review, so GreenBasket adds a human review route and monitors abandonment. Payout fraud attempts become easier to detect because changes generate alerts and cannot take effect immediately.

Learning points

The case demonstrates that payment security is an ecosystem problem. A hosted payment page reduces exposure but does not solve account takeover, webhook abuse, social engineering, or poor dispute communication. Effective controls combine technology, process, people, supplier governance, and customer support.

10. Ethical, Regulatory, and Contemporary Issues

Payment entrepreneurs must consider more than revenue and conversion. They should avoid dark patterns that pressure customers into subscriptions, obscure fees, or make cancellation deliberately difficult. Risk scoring should be proportionate and tested for discriminatory effects. Data should not be retained merely because future monetization is possible.

Applicable obligations vary by country and business model, but may include payment-services licensing, consumer protection, privacy and breach-notification law, anti-money-laundering and know-your-customer requirements, electronic-transaction rules, tax records, accessibility duties, and payment-card security standards. Students and entrepreneurs should obtain jurisdiction-specific advice rather than assuming that a foreign platform’s terms satisfy local law.

Artificial intelligence can assist anomaly detection, customer-support triage, and adaptive risk scoring. It can also amplify bias, generate opaque decisions, expose sensitive data through poorly governed tools, or create false confidence. Human review, documented model purpose, data quality controls, monitoring, explainability appropriate to the use case, and an appeal process are essential. AI should support—not replace—accountability for payment and security decisions.

Best-Practice Checklist

A responsible digital venture should:

• choose payment providers after assessing fees, settlement, reliability, security, privacy, and dispute support;
• minimize handling of raw payment credentials;
• use multifactor authentication for administrators and high-risk users;
• verify server-side payment status and signed provider events;
• use idempotency and reconciliation to prevent duplicate or missing transactions;
• separate payment, refund, payout, and administrative privileges;
• monitor fraud, false positives, disputes, refunds, and unusual account activity;
• maintain tested backups, logs, contact lists, and an incident-response plan;
• communicate prices, billing descriptors, delivery, refunds, and cancellation terms clearly;
• document data purposes, retention, suppliers, and breach responsibilities;
• test controls and review them as the venture, threat environment, and legal context change.

Chapter Summary

Digital payments are socio-technical systems involving customers, merchants, gateways, processors, issuers, acquirers, networks, and regulators. Gateways and PSPs simplify acceptance, while cards, wallets, bank transfers, and embedded finance offer different combinations of convenience, cost, reach, control, and risk. Payment economics include transaction fees, settlement timing, fraud, disputes, operational effort, and lost conversion.

Trust is supported by authentication, authorization, encryption, tokenization, secure software, transparent policies, and dependable fulfilment. Fraud management requires layered preventive, detective, responsive, and corrective controls. Chargebacks should be managed through accurate transaction records, clear customer communication, relevant evidence, and root-cause prevention.

Privacy-by-design requires minimization, purpose limitation, transparency, retention control, secure defaults, and accountability. Risk management links assets, threats, vulnerabilities, impacts, controls, owners, and treatment decisions. Incident response proceeds through preparation, detection, containment, eradication, recovery, and learning. Entrepreneurs who integrate security, privacy, payment operations, ethics, and customer experience are better positioned to build durable digital ventures.

Key Terms

Payment gateway: A technical service that securely connects checkout software with payment infrastructure.

Payment service provider: A provider combining payment processing and related services for merchants.

Acquirer: An institution or service receiving card transactions for a merchant.

Issuer: The institution that issues a payment card or account to a customer.

Authorization: Approval or denial of a proposed transaction.

Clearing: Exchange and reconciliation of transaction information before settlement.

Settlement: Transfer of funds between relevant payment participants.

Digital wallet: A software or device-based service storing credentials or payment value.

Embedded finance: Financial services integrated into a non-financial platform or application.

Tokenization: Replacement of sensitive data with a substitute token.

Encryption: Transformation of readable data into protected ciphertext using a key.

Authentication: Verification of an actor’s identity.

Authorization: Determination of what an authenticated actor may do.

Idempotency: Property whereby repeating a request does not create an unintended duplicate effect.

Chargeback: A payment reversal initiated through a card issuer or payment network after a dispute.

Privacy-by-design: Incorporating privacy protections into systems from the planning stage.

Data minimization: Collection and use of only the data necessary for a defined purpose.

Least privilege: Giving users and systems only the access required for their roles.

Incident response: Organized detection, containment, recovery, and learning following a security event.

Residual risk: Risk remaining after controls and treatments have been applied.

Review Questions

5 Short Answer Questions

1. What is the difference between a payment gateway and a payment processor?
2. Distinguish authentication from authorization.
3. State two advantages and two risks of digital wallets.
4. What is a chargeback, and how does it differ from an ordinary customer complaint?
5. Explain the purpose of idempotency in payment software.

5 Long Answer Questions

1. Compare cards, wallets, bank transfers, and embedded finance in terms of convenience, cost, control, and risk.
2. Explain how encryption, hashing, and tokenization differ and identify suitable uses for each.
3. Discuss privacy-by-design principles and apply them to an online subscription business.
4. Explain the stages of an effective incident-response lifecycle.
5. Analyse how an entrepreneur should select a payment service provider beyond comparing transaction fees.

3 Analytical / Application Questions

1. A marketplace experiences rising chargebacks and fraudulent seller payout changes. Construct a risk register and recommend technical, procedural, and governance controls.
2. A payment provider charges 2.5% plus 0.30 currency units per transaction. Calculate the fee on an 80-unit sale and explain why the fee structure matters more for low-value transactions.
3. A business wants to use AI to decline transactions automatically. Evaluate the benefits, privacy risks, fairness concerns, human-oversight requirements, and performance measures that should be considered before deployment.

Multiple Choice Questions with Answers

Question 1

Which party normally issues a customer’s payment card?

A. The acquirer

B. The issuer

C. The payment gateway

D. The merchant

Correct Answer: B. The issuer

Question 2

A payment gateway primarily performs which function?

A. Manufacturing payment cards

B. Setting consumer tax rates

C. Securely connecting checkout software to payment infrastructure

D. Delivering purchased goods

Correct Answer: C. Securely connecting checkout software to payment infrastructure

Question 3

Using F = rP + f, what is the fee when P = 80, r = 0.025, and f = 0.30?

A. 1.75 currency units

B. 2.00 currency units

C. 2.30 currency units

D. 2.80 currency units

Correct Answer: C. 2.30 currency units

Question 4

Which practice best illustrates tokenization?

A. Replacing a payment credential with a substitute value

B. Sending a password by email

C. Deleting all transaction records immediately

D. Making a payment page visually attractive

Correct Answer: A. Replacing a payment credential with a substitute value

Question 5

What does idempotency help prevent?

A. All customer complaints

B. Unintended duplicate effects from repeated requests

C. Currency conversion

D. The need for transaction reconciliation

Correct Answer: B. Unintended duplicate effects from repeated requests

Question 6

Which is an example of privacy-by-design?

A. Collecting every possible customer attribute for future use

B. Retaining payment data indefinitely

C. Collecting only data necessary for a defined purpose

D. Sharing customer data without notice

Correct Answer: C. Collecting only data necessary for a defined purpose

Question 7

Which incident-response stage focuses on limiting the spread of a compromise?

A. Containment

B. Marketing

C. Settlement

D. Product pricing

Correct Answer: A. Containment

Question 8

Which control is most appropriate for protecting administrator accounts?

A. A shared password used by the whole team

B. Multifactor authentication and least privilege

C. Disabling all system logs

D. Relying only on customer support

Correct Answer: B. Multifactor authentication and least privilege

Question 9

What is a chargeback?

A. A routine payment authorization

B. A payment reversal initiated through a card issuer or network after a dispute

C. A merchant’s monthly subscription fee

D. A customer’s delivery confirmation

Correct Answer: B. A payment reversal initiated through a card issuer or network after a dispute

Question 10

Why should payment status be verified server-side?

A. Browser messages can be manipulated or may not reflect final provider status

B. It eliminates the need for encryption

C. It guarantees that no transaction can be disputed

D. It prevents customers from using wallets

Correct Answer: A. Browser messages can be manipulated or may not reflect final provider status