安全電子交易協議具體條款

⑴ 電子商務中的安全協議是什麼意思

安全協議是以密碼學為基礎的消息交換協議，其目的是在網路環境中提供各種安全服務。密碼學是網路安全的基礎，但網路安全不能單純依靠安全的密碼演算法。安全協議是網路安全的一個重要組成部分，我們需要通過安全協議進行實體之間的認證、在實體之間安全地分配密鑰或其它各種秘密、確認發送和接收的消息的非否認性等。

安全協議是建立在密碼體制基礎上的一種交互通信協議，它運用密碼演算法和協議邏輯來實現認證和密鑰分配等目標。

安全協議可用於保障計算機網路信息系統中秘密信息的安全傳遞與處理，確保網路用戶能夠安全、方便、透明地使用系統中的密碼資源。安全協議在金融系統、商務系統、政務系統、軍事系統和社會生活中的應用日益普遍，而安全協議的安全性分析驗證仍是一個懸而未決的問題。在實際社會中，有許多不安全的協議曾經被人們作為正確的協議長期使用，如果用於軍事領域的密碼裝備中，則會直接危害到軍事機密的安全性，會造成無可估量的損失。這就需要對安全協議進行充分的分析、驗證，判斷其是否達到預期的安全目標。

網路安全是實現電子商務的基礎，而一個通用性強，安全可靠的網路協議則是實現電子商務安全交易的關鍵技術之一，它也會對電子商務的整體性能產生很大的影響。由美國Netscape公司開發和倡導的SSL協議（Secure Sockets Layer，安全套接層），它是目前安全電子商務交易中使用最多的協議之一，內容主要包括協議簡介、記錄協議、握手協議、協議安全性分析以及應用等。本文在簡單介紹SSL協議特點和流程的基礎上，詳細介紹了SSL協議的應用和配置過程。

1 、SSL協議簡介

SSL作為目前保護Web安全和基於HTTP的電子商務交易安全的事實上的，被許多世界知名廠商的Intranet和Internet網路產品所支持，其中包括Netscape、Microsoft、IBM 、Open Market等公司提供的支持SSL的客戶機和伺服器產品，如IE和Netscape瀏覽器，IIS、Domino Go WebServer、Netscape Enterprise Server和Appache等Web Server等。

SSL採用對稱密碼技術和公開密碼技術相結合，提供了如下三種基本的安全服務：秘密性。SSL客戶機和伺服器之間通過密碼演算法和密鑰的協商，建立起一個安全通道。以後在安全通道中傳輸的所有信息都經過了加密處理，網路中的非法竊聽者所獲取的信息都將是無意義的密文信息。

完整性。SSL利用密碼演算法和hash函數，通過對傳輸信息特徵值的提取來保證信息的完整性，確保要傳輸的信息全部到達目的地，可以避免伺服器和客戶機之間的信息內容受到破壞。

認證性。利用證書技術和可信的第三方CA，可以讓客戶機和伺服器相互識別的對方的身份。為了驗證證書持有者是其合法用戶(而不是冒名用戶)，SSL要求證書持有者在握手時相互交換數字證書，通過驗證來保證對方身份的合法性。

SSL協議的實現屬於SOCKET層，處於應用層和傳輸層之間，由SSL記錄協議（SSL RECORD PROTOCOL）和SSL握手協議（SSL HAND-SHAKE PROTOCOL）組成的，其結構如圖1所示：

SSL可分為兩層，一是握手層，二是記錄層。SSL握手協議描述建立安全連接的過程，在客戶和伺服器傳送應用層數據之前，完成諸如加密演算法和會話密鑰的確定，通信雙方的身份驗證等功能；SSL記錄協議則定義了數據傳送的格式，上層數據包括SSL握手協議建立安全連接時所需傳送的數據都通過SSL記錄協議再往下層傳送。這樣，應用層通過SSL協議把數據傳給傳輸層時，已是被加密後的數據，此時TCP/IP協議只需負責將其可靠地傳送到目的地，彌補了 TCP/IP協議安全性較差的弱點。

Netscape公司已經向公眾推出了SSL的參考實現（稱為SSLref）。另一免費的SSL實現叫做SSLeay。SSLref和SSLeay均可給任何TCP/IP應用提供SSL功能，並且提供部分或全部源代碼。Internet號碼分配當局（IANA）已經為具備SSL功能的應用分配了固定埠號，例如，帶SSL的HTTP（https）被分配以埠號443，帶SSL的SMTP（ssmtp）被分配以埠號465，帶SSL的NNTP （snntp）被分配以埠號563。

微軟推出了SSL版本2的改進版本，叫做PCT（私人通信技術）。SSL和PCT非常類似。它們的主要差別是它們在版本號欄位的最顯著位（The Most Significant Bit）上的取值有所不同：SSL該位取0，PCT該位取1。這樣區分之後，就可以對這兩個協議都給予支持。

1996年4月，IETF授權一個傳輸層安全（TLS）工作組著手制訂一個傳輸層安全協議（TLSP），以便作為標准提案向IESG正式提交。TLSP將會在許多地方酷似SSL。

2 、SSL安全性

目前，幾乎所有操作平台上的WEB瀏覽器（IE、Netscatp）以及流行的Web伺服器（IIS、Netscape Enterprise Server等）都支持SSL協議。因此使得使用該協議便宜且開發成本小。但應用SSL協議存在著不容忽視的缺點：

1. 系統不符合國務院最新頒布的《商用密碼管理條例》中對商用密碼產品不得使用國外密碼演算法的規定，要通過國家密碼管理委員會的審批會遇到相當困難。

2. 系統安全性差。SSL協議的數據安全性其實就是建立在RSA等演算法的安全性上，因此從本質上來講，攻破RSA等演算法就等同於攻破此協議。由於美國政府的出口限制，使得進入我國的實現了SSL的產品（Web瀏覽器和伺服器）均只能提供512比特RSA公鑰、40比特對稱密鑰的加密。目前已有攻破此協議的例子：1995年8月，一個法國學生用上百台工作站和二台小型機攻破了Netscape對外出口版本；另外美國加州兩個大學生找到了一個「陷門」，只用了一台工作站幾分鍾就攻破了Netscape對外出口版本。

但是，一個安全協議除了基於其所採用的加密演算法安全性以外，更為關鍵的是其邏輯嚴密性、完整性、正確性，這也是研究協議安全性的一個重要方面，如果一個安全協議在邏輯上有問題，那麼它的安全性其實是比它所採用的加密演算法的安全性低，很容易被攻破。從目前來看，SSL比較好地解決了這一問題。不過SSL協議的邏輯體現在SSL握手協議上，SSL握手協議本身是一個很復雜的過程，情況也比較多，因此我們並不能保證SSL握手協議在所有的情況下邏輯上都是正確的，所以研究SSL協議的邏輯正確性是一個很有價值的問題。

另外，SSL協議在「重傳攻擊」上，有它獨到的解決辦法。SSL協議為每一次安全連接產生了一個128位長的隨機數——「連接序號」。理論上，攻擊者提前無法預測此連接序號，因此不能對伺服器的請求做出正確的應答。但是計算機產生的隨機數是偽隨機數，它的實際周期要遠比2128小，更為危險的是有規律性，所以說SSL協議並沒有從根本上解決「信息重傳」這種攻擊方法，有效的解決方法是採用「時間戳」。但是這需要解決網路上所有節點的時間同步問題。

總的來講，SSL協議的安全性能是好的，而且隨著SSL協議的不斷改進，更多的安全性能、好的加密演算法被採用，邏輯上的缺陷被彌補，SSL協議的安全性能會不斷加強。

3、 windows 2000中SSL的配置與應用SSL的典型應用主要有兩個方面，一是客戶端，如瀏覽器等；另外一個就是伺服器端，如Web伺服器和應用伺服器等。目前，一些主流瀏覽器（如IE和 Netscape等）和IIS、Domino Go WebServer、Netscape Enterprise Server、Appache等Web伺服器都提供了對SSL的支持。要實現瀏覽器（或其他客戶端應用）和Web伺服器（或其他伺服器）之間的安全SSL 信息傳輸，必須在Web伺服器端安裝支持SSL的Web伺服器證書，在瀏覽器端安裝支持SSL的客戶端證書（可選），然後把URL中的「http://」 更換。

⑵ 安全電子交易協議英文

SET= Secure Electronic Transaction

⑶ 安全電子交易協議的簡介

People today pay for online purchases by sending their credit card details to the merchant. A protocol such as SSL or TLS keeps the card details safe from eavesdroppers, but does nothing to protect merchants from dishonest customers or vice-versa. SET addresses this situation by requiring cardholders and merchants to register before they may engage in transactions. A cardholder registers by contacting a certificate authority, supplying security details and the public half of his proposed signature key. Registration allows the authorities to vet an applicant, who if approved receives a certificate confirming that his signature key is valid. All orders and confirmations bear digital signatures, which provide authentication and could potentially help to resolve disputes.
A SET purchase involves three parties: the cardholder, the merchant, and the payment gateway (essentially a bank). The cardholder shares the order information with the merchant but not with the payment gateway. He shares the payment information with the bank but not with the merchant. A set al signature accomplishes this partial sharing of information while allowing all parties to confirm that they are handling the same transaction. The method is simple: each party receives the hash of the withheld information. The cardholder signs the hashes of both the order information and the payment information. Each party can confirm that the hashes in their possession agrees with the hash signed by the cardholder. In addition, the cardholder and merchant compute equivalent hashes for the payment gateway to compare. He confirms their agreement on the details withheld from him.
All parties are protected. Merchants do not normally have access to credit card numbers. Moreover, the mere possession of credit card details does not enable a criminal to make a SET purchase; he needs the cardholder』s signature key and a secret number that the cardholder receives upon registration. The criminal would have better luck with traditional frauds, such as ordering by telephone. It is a pity that other features of SET (presumably demanded by merchants) weaken these properties. A merchant can be authorized to receive credit card numbers and has the option of accepting payments given a credit card number alone.
SET is a family of protocols. The five main ones are cardholder registration, merchant registration, purchase request, payment authorization, and payment capture. There are many minor protocols, for example to handle errors. SET is enormously more complicated than SSL, which merely negotiates session keys between the cardholder』s and merchant』s Internet service providers. Because of this complexity, much of which is unnecessary, the protocol is hardly used. However, SET contains many features of interest:
The model is unusual. In the registration protocols, the initiator possesses no digital proof of identity. Instead, he authenticates himself by filing a registration form whose format is not specified. Authentication takes place outside the protocol, when the cardholder』s bank examines the completed form.
The al signature is a novel construction. The partial sharing of information among three peers leads to unusual protocol goals.
SET uses several types of digital envelope. A digital envelope consists of two parts: one, encrypted using a public key, contains a fresh symmetric key K and identifying information; the other, encrypted using K, conveys the full message text. Digital envelopes keep public-key encryption to a minimum, but the many symmetric keys complicate the reasoning. Most verified protocols distribute just one or two secrets.

⑷ 支付寶使用哪些安全協議

支付寶採用SET協議保證安全性。
安全電子交易協議 (Secure Electronic Transaction,簡稱SET協議)，是基於信用卡在線支付的電於商務安全協議，它是由VISA和MasterCard兩大信用卡公司於1997年5月聯合推出的規范。SET主要是為了解決用戶、商家和銀行之間通過信用卡支付的交易而設計的，以保證支付命令的機密、支付過程的完整、商戶及持卡人的合法身份，以及可操作性。SET通過制定標准和採用各種密碼技術手段，解決了當時困擾電子商務發展的安全問題。
SET是在開放網路環境中的卡支付安全協議，它採用公鑰密碼體制(PKI)和X.509電子證書標准，通過相應軟體、電子證書、數字簽名和加密技術能在電子交易環節上提供更大的信任度、更完整的交易信息、更高的安全性和更少受欺詐的可能性。SET協議用以支持B-C這種類型的電子商務模式，即消費者持卡在網上購物與交易的模式。
SET協議的功能
SET協議是信用卡在網際網路上進行支付的一種開放式安全協議和格式。解決持卡人、商家和銀行之間通過信用卡來進行網上支付的交易，旨在保證支付命令的機密性、支付過程的完整性、商家以及持卡人身份的合法性以及可操作性。
SET協議採用的加密和認證技術
SET使用多種密鑰技術來達到安全交易的要求，其中對稱密鑰技術、公鑰加密技術和Hash演算法是其核心。綜合應用以上三種技術產生了數字簽名、數字信封、數字證書等加密與認證技術。
SET標準的應用與局限性
SET 1.0版自1997年推出以來推廣應用較慢，沒有達到預期的效果。最大的挑戰在於定期進行網上購物的消費者極少，原因主要是SET協議為了保證安全性而犧牲了簡便性、操作過於復雜、成本較高、具有較大競爭力的SSL協議的廣泛應用以及部分經濟發達國家的法律規定了持卡人承擔較低的信用卡風險等。SET協議提供了多層次安全保障，復雜程度顯著增加；這些安全環節在一定程度上增加了交易的復雜性。
另外，SET協議目前只局限於銀行卡的網上支付，對其他方式的支付沒有給出很好的解決方案。SET協議只支持B2C模式的電子商務，而不支持目前最具有前途和影響力的B2B電子商務交易。
SET由於其高度的安全性和規范性，使其逐步發展成為目前安全電子支付的國際標准。由於SSL協議的成本低、速度快、使用簡單，對現有網路系統不需進行大的修改，因而目前取得了廣泛的應用。但隨著電子商務規模的擴大，網路欺詐的風險性也在提高，在未來的電子商務中SET協議將會逐步占據主導地位。

⑸ 目前功能較強的安全電子交易協議是什麼

(secure Electronic Transaction簡稱SET) 由威士(VISA)國際組織、萬事達(MasterCard)國際組織創建，結合IBM、Microsoft、Netscope、GTE等公司制定的電子商務中安全電子交易的一個國際標准。其主要目的是解決信用卡電子付款的安全保障性問題，這包括：保證信息的機密性，保證信息安全傳輸，不能被竊聽，只有收件人才能得到和解密信息；保證支付信息的完整性，保證傳輸數據完整接收，在中途不被篡改；認證商家和客戶，驗證公共網路上進行交易活動包括會計機構的設置、會計人員的配備及其職責權利的履行和會計法規、制度的制定與實施等內容。合理、有效地組織會計I作，意義重大，它有助於提高會計信息質量，執行國家財經紀律和有關規定；有助於提高經濟效益，優化資源配置。會計工作的組織必須合法合規。講求效益，必須建立完善的內部控制制度，必須有強有力的組織保證。

⑹ 安全電子交易協議的SET系統的組成

SET支付系統主要由持卡人（CardHolder）、商家（Merchant）、發卡行（Issuing Bank）、收單行（Acquiring Bank）、支付網關（Payment Gateway）、認證中心（Certificate Authority）等六個部分組成。對應地，基於SET協議的網上購物系統至少包括電子錢包軟體、商家軟體、支付網關軟體和簽發證書軟體。

⑺ 安全電子支付的法律法規

第一條為規范和引導電子支付的健康發展，保障當事人的合法權益，防範支付風險，確保銀行和客戶資金的安全，制定本指引。
第二條電子支付是指單位、個人（以下簡稱客戶）直接或授權他人通過電子終端發出支付指令，實現貨幣支付與資金轉移的行為。
電子支付的類型按電子支付指令發起方式分為網上支付、電話支付、移動支付、銷售點終端交易、自動櫃員機交易和其他電子支付。
境內銀行業金融機構（以下簡稱銀行）開展電子支付業務，適用本指引。
第三條銀行開展電子支付業務應當遵守國家有關法律、行政法規的規定，不得損害客戶和社會公共利益。
銀行與其他機構合作開展電子支付業務的，其合作機構的資質要求應符合有關法規制度的規定，銀行要根據公平交易的原則，簽訂書面協議並建立相應的監督機制。 第四條客戶辦理電子支付業務應在銀行開立銀行結算賬戶（以下簡稱賬戶），賬戶的開立和使用應符合《人民幣銀行結算賬戶管理辦法》、《境內外匯賬戶管理規定》等規定。 第五條電子支付指令與紙質支付憑證可以相互轉換，二者具有同等效力。
第六條本指引下列用語的含義為：
（一）「發起行」，是指接受客戶委託發出電子支付指令的銀行。
（二）「接收行」，是指電子支付指令接收人的開戶銀行；接收人未在銀行開立賬戶的，指電子支付指令確定的資金匯入銀行。
（三）「電子終端」，是指客戶可用以發起電子支付指令的計算機、電話、銷售點終端、自動櫃員機、移動通訊工具或其他電子設備。
第二章電子支付業務的申請
第七條銀行應根據審慎性原則，確定辦理電子支付業務客戶的條件。
第八條辦理電子支付業務的銀行應公開披露以下信息：
（一）銀行名稱、營業地址及聯系方式；
（二）客戶辦理電子支付業務的條件；
（三）所提供的電子支付業務品種、操作程序和收費標准等；
（四）電子支付交易品種可能存在的全部風險，包括該品種的操作風險、未採取的安全措施、無法採取安全措施的安全漏洞等；
（五）客戶使用電子支付交易品種可能產生的風險；
（六）提醒客戶妥善保管、使用或授權他人使用電子支付交易存取工具（如卡、密碼、密鑰、電子簽名製作數據等）的警示性信息；
（七）爭議及差錯處理方式。
第九條銀行應認真審核客戶申請辦理電子支付業務的基本資料，並以書面或電子方式與客戶簽訂協議。
銀行應按會計檔案的管理要求妥善保存客戶的申請資料，保存期限至該客戶撤銷電子支付業務後5年。
第十條銀行為客戶辦理電子支付業務，應根據客戶性質、電子支付類型、支付金額等，與客戶約定適當的認證方式，如密碼、密鑰、數字證書、電子簽名等。 認證方式的約定和使用應遵循《中華人民共和國電子簽名法》等法律法規的規定。
第十一條銀行要求客戶提供有關資料信息時，應告知客戶所提供信息的使用目的和范圍、安全保護措施、以及客戶未提供或未真實提供相關資料信息的後果。 第十二條客戶可以在其已開立的銀行結算賬戶中指定辦理電子支付業務的賬戶。該賬戶也可用於辦理其他支付結算業務。
客戶未指定的銀行結算賬戶不得辦理電子支付業務。
第十三條客戶與銀行簽訂的電子支付協議應包括以下內容：
（一）客戶指定辦理電子支付業務的賬戶名稱和賬號；
（二）客戶應保證辦理電子支付業務賬戶的支付能力；
（三）雙方約定的電子支付類型、交易規則、認證方式等；
（四）銀行對客戶提供的申請資料和其他信息的保密義務；
（五）銀行根據客戶要求提供交易記錄的時間和方式；
（六）爭議、差錯處理和損害賠償責任。
第十四條有以下情形之一的，客戶應及時向銀行提出電子或書面申請：
（一）終止電子支付協議的；
（二）客戶基本資料發生變更的；
（三）約定的認證方式需要變更的；
（四）有關電子支付業務資料、存取工具被盜或遺失的；
（五）客戶與銀行約定的其他情形。
第十五條客戶利用電子支付方式從事違反國家法律法規活動的，銀行應按照有權部門的要求停止為其辦理電子支付業務。
第三章電子支付指令的發起和接收
第十六條客戶應按照其與發起行的協議規定，發起電子支付指令。
第十七條電子支付指令的發起行應建立必要的安全程序，對客戶身份和電子支付指令進行確認，並形成日誌文件等記錄，保存至交易後5年。
第十八條發起行應採取有效措施，在客戶發出電子支付指令前，提示客戶對指令的准確性和完整性進行確認。
第十九條發起行應確保正確執行客戶的電子支付指令，對電子支付指令進行確認後，應能夠向客戶提供紙質或電子交易回單。
發起行執行通過安全程序的電子支付指令後，客戶不得要求變更或撤銷電子支付指令。
第二十條發起行、接收行應確保電子支付指令傳遞的可跟蹤稽核和不可篡改。
第二十一條發起行、接收行之間應按照協議規定及時發送、接收和執行電子支付指令，並回復確認。
第二十二條電子支付指令需轉換為紙質支付憑證的，其紙質支付憑證必須記載以下事項(具體格式由銀行確定)：
（一）付款人開戶行名稱和簽章；
（二）付款人名稱、賬號；
（三）接收行名稱；
（四）收款人名稱、賬號；
（五）大寫金額和小寫金額；
（六）發起日期和交易序列號。
第四章安全控制
第二十三條銀行開展電子支付業務採用的信息安全標准、技術標准、業務標准等應當符合有關規定。
第二十四條銀行應針對與電子支付業務活動相關的風險，建立有效的管理制度。
第二十五條銀行應根據審慎性原則並針對不同客戶，在電子支付類型、單筆支付金額和每日累計支付金額等方面做出合理限制。
銀行通過互聯網為個人客戶辦理電子支付業務，除採用數字證書、電子簽名等安全認證方式外，單筆金額不應超過1000元人民幣，每日累計金額不應超過5000元人民幣。 銀行為客戶辦理電子支付業務，單位客戶從其銀行結算賬戶支付給個人銀行結算賬戶的款項，其單筆金額不得超過5萬元人民幣，但銀行與客戶通過協議約定，能夠事先提供有效付款依據的除外。 銀行應在客戶的信用卡授信額度內，設定用於網上支付交易的額度供客戶選擇，但該額度不得超過信用卡的預借現金額度。
第二十六條銀行應確保電子支付業務處理系統的安全性，保證重要交易數據的不可抵賴性、數據存儲的完整性、客戶身份的真實性，並妥善管理在電子支付業務處理系統中使用的密碼、密鑰等認證數據。 第二十七條銀行使用客戶資料、交易記錄等，不得超出法律法規許可和客戶授權的范圍。
銀行應依法對客戶的資料信息、交易記錄等保密。除國家法律、行政法規另有規定外，銀行應當拒絕除客戶本人以外的任何單位或個人的查詢。
第二十八條銀行應與客戶約定，及時或定期向客戶提供交易記錄、資金余額和賬戶狀態等信息。
第二十九條銀行應採取必要措施保護電子支付交易數據的完整性和可靠性：
（一）制定相應的風險控制策略，防止電子支付業務處理系統發生有意或無意的危害數據完整性和可靠性的變化，並具備有效的業務容量、業務連續性計劃和應急計劃; （二）保證電子支付交易與數據記錄程序的設計發生擅自變更時能被有效偵測；
（三）有效防止電子支付交易數據在傳送、處理、存儲、使用和修改過程中被篡改，任何對電子支付交易數據的篡改能通過交易處理、監測和數據記錄功能被偵測； （四）按照會計檔案管理的要求，對電子支付交易數據，以紙介質或磁性介質的方式進行妥善保存，保存期限為5年，並方便調閱。
第三十條銀行應採取必要措施為電子支付交易數據保密：
（一）對電子支付交易數據的訪問須經合理授權和確認；
（二）電子支付交易數據須以安全方式保存，並防止其在公共、私人或內部網路上傳輸時被擅自查看或非法截取；
（三）第三方獲取電子支付交易數據必須符合有關法律法規的規定以及銀行關於數據使用和保護的標准與控制制度；
（四）對電子支付交易數據的訪問均須登記，並確保該登記不被篡改。
第三十一條銀行應確保對電子支付業務處理系統的操作人員、管理人員以及系統服務商有合理的授權控制：
（一）確保進入電子支付業務賬戶或敏感系統所需的認證數據免遭篡改和破壞。對此類篡改都應是可偵測的，而且審計監督應能恰當地反映出這些篡改的企圖。 （二）對認證數據進行的任何查詢、添加、刪除或更改都應得到必要授權，並具有不可篡改的日誌記錄。
第三十二條銀行應採取有效措施保證電子支付業務處理系統中的職責分離：
（一）對電子支付業務處理系統進行測試，確保職責分離；
（二）開發和管理經營電子支付業務處理系統的人員維持分離狀態；
（三）交易程序和內控制度的設計確保任何單個的雇員和外部服務供應商都無法獨立完成一項交易。
第三十三條銀行可以根據有關規定將其部分電子支付業務外包給合法的專業化服務機構，但銀行對客戶的義務及相應責任不因外包關系的確立而轉移。
銀行應與開展電子支付業務相關的專業化服務機構簽訂協議，並確立一套綜合性、持續性的程序，以管理其外包關系。
第三十四條銀行採用數字證書或電子簽名方式進行客戶身份認證和交易授權的，提倡由合法的第三方認證機構提供認證服務。如客戶因依據該認證服務進行交易遭受損失，認證服務機構不能證明自己無過錯，應依法承擔相應責任。 第三十五條境內發生的人民幣電子支付交易信息處理及資金清算應在境內完成。
第三十六條銀行的電子支付業務處理系統應保證對電子支付交易信息進行完整的記錄和按有關法律法規進行披露。
第三十七條銀行應建立電子支付業務運作重大事項報告制度，及時向監管部門報告電子支付業務經營過程中發生的危及安全的事項。
第五章差錯處理
第三十八條電子支付業務的差錯處理應遵守據實、准確和及時的原則。
第三十九條銀行應指定相應部門和業務人員負責電子支付業務的差錯處理工作，並明確許可權和職責。
第四十條銀行應妥善保管電子支付業務的交易記錄，對電子支付業務的差錯應詳細備案登記，記錄內容應包括差錯時間、差錯內容與處理部門及人員姓名、客戶資料、差錯影響或損失、差錯原因、處理結果等。 第四十一條由於銀行保管、使用不當，導致客戶資料信息被泄露或篡改的，銀行應採取有效措施防止因此造成客戶損失，並及時通知和協助客戶補救。
第四十二條因銀行自身系統、內控制度或為其提供服務的第三方服務機構的原因，造成電子支付指令無法按約定時間傳遞、傳遞不完整或被篡改，並造成客戶損失的，銀行應按約定予以賠償。 因第三方服務機構的原因造成客戶損失的，銀行應予賠償，再根據與第三方服務機構的協議進行追償。
第四十三條接收行由於自身系統或內控制度等原因對電子支付指令未執行、未適當執行或遲延執行致使客戶款項未准確入賬的，應及時糾正。
第四十四條客戶應妥善保管、使用電子支付交易存取工具。有關電子支付業務資料、存取工具被盜或遺失，應按約定方式和程序及時通知銀行。
第四十五條非資金所有人盜取他人存取工具發出電子支付指令，並且其身份認證和交易授權通過發起行的安全程序的，發起行應積極配合客戶查找原因，盡量減少客戶損失。 第四十六條客戶發現自身未按規定操作，或由於自身其他原因造成電子支付指令未執行、未適當執行、延遲執行的，應在協議約定的時間內，按照約定程序和方式通知銀行。銀行應積極調查並告知客戶調查結果。 銀行發現因客戶原因造成電子支付指令未執行、未適當執行、延遲執行的，應主動通知客戶改正或配合客戶採取補救措施。
第四十七條因不可抗力造成電子支付指令未執行、未適當執行、延遲執行的，銀行應當採取積極措施防止損失擴大。
第六章附則
第四十八條本指引由中國人民銀行負責解釋和修改。
第四十九條本指引自發布之日起施行。希望能幫助到樓主