在通過網路進行的各種事務中，事務的進行常常伴隨著資源在網路節點間的流動。在一種事務中，由資源由一個到多個起始節點流向一個目標節點，目標節點按照事務的資源轉移總額度，確定各個起始節點的轉移份額，然後分別向各個起始節點發送資源轉移通知，在資源轉移通知中攜帶有該起始節點需要轉移給目標節點的轉移份額。起始節點根據資源轉移通知中的轉移份額將自身的資源轉移至目標節點。 本發明的實施例一針對上述事務提出一種資源轉移的實現方法，能夠在事務的進行過程中和進行完畢後，在目標節點上通過更改轉移參數，使得資源轉移的結果自動校正為匹配於更改後的轉移參數，在應用於收付款時能夠避免人工計算和操作過程，以解決現有技術中存在的問題。 本發明的實施例一中，起始節點和目標節點之間通過網路可以相互存取。起始節點和目標節點可以是任何具有計算和儲存能力的設備，如手機、平板電腦、PC(Personal Computer，個人電腦)、筆記型電腦、伺服器等設備；還可以由運行在兩個或兩個以上設備的邏輯節點來實現本發明實施例中起始節點或目標節點的各項功能。 本發明的實施例一中，資源轉移的實現方法應用在目標節點上的流程如圖1所示，應用在起始節點上的流程如圖2所示。 在目標節點上，步驟110，接收對轉移參數的更改。 在事務啟動後，目標節點與起始節點之間即可按照初始的轉移參數來進行資源的轉移。在事務的進行過程中或事務結束後，即資源轉移的過程中或資源轉移完畢後，可以對目標節點上的轉移參數進行更改。對轉移參數的更改可以由人工進行，也可以由網路中其他具有管理許可權的節點自動進行，不做限定。 在涉及資源轉移的事務中，轉移參數通常可以包括資源轉移總額度、起始節點數量、每個起始節點等等。 在目標節點上，步驟120，按照更改後的轉移參數和起始節點的轉移狀態，執行以下動作中的至少一個：通知至少一個起始節點需轉移的資源份額、向至少一個起始節點退回部分或全部已轉移的資源。 如前所述，在事務啟動後，目標節點會按照初始的轉移參數，確定每個起始節點的轉移份額，並通知各個起始節點進行資源的轉移。在目標節點收到對轉移參數的更改時，事務已經在進行或者已經進行完畢，起始節點的轉移狀態包括兩種：已轉移資源(已經按照初始的轉移參數確定的轉移份額完成資源轉移)、或者未轉移資源(尚未進行資源轉移)。 目標節點在收到更改後的轉移參數後，按照更改後的轉移參數確定每個起始節點更改後的轉移份額，根據每個起始節點的轉移狀態，向已轉移的資源超過更改後份額的起始節點退回超額轉移的部分資源(更改前與更改後該起始節點轉移份額的差額)，通知已轉移的資源不足更改後份額的起始節點需要繼續轉移的份額(更改前與更改後該起始節點轉移份額的差額)，通知未轉移資源的起始節點其轉移份額(按照更改後轉移參數確定的轉移份額)。 在一種實現方式中，可供更改的轉移參數包括增加起始節點、刪除起始節點、更改資源轉移總額度中的一個到多個。在收到對轉移參數的更改後，目標節點按照對起始節點的更改確定當前的起始節點、或當前的起始節點和被刪除的前起始節點。具體而言，如果沒有刪除原來的起始節點，則確定當前的起始節點；如果刪除了原來的起始節點，則確定當前的起始節點和被刪除的前起始節點。目標節點按照更改後的資源轉移總額度確定每個起始節點(即當前的起始節點)更改後的轉移份額。對每個已轉移資源的起始節點，當更改後的轉移份額小於更改前的轉移份額時，目標節點將多轉移的份額退回給起始節點；當更改後的轉移份額大於更改前的轉移份額時，目標節點通知該起始節點需繼續轉移的份額。對每個未轉移資源的起始節點，當更改後的轉移份額與更改前的轉移份額不同、或者該起始節點為新增的起始節點時，按照更改後的轉移份額通知該起始節點需轉移的份額。對前起始節點，如果已轉移資源則目標節點向該前起始節點退回已轉移的份額，否則目標節點通知該前起始節點無需進行資源轉移。 在目標節點向起始節點退回已轉移的部分或全部資源後，目標節點可以向起始節點發送資源退回的通知，將資源已退回的狀態告知起始節點。 在起始節點上，步驟210，接收資源退回通知或資源轉移通知。 當更改後的轉移份額少於更改前的轉移份額時、或者當起始節點被刪除成為前起始節點時，處於已轉移資源狀態的起始節點會從目標節點收到資源退回通知。資源退回通知中包括退回的額度，還可以包括導致資源退回的原因(如對轉移參數的更改)等。 當更改後的轉移份額多於更改前的轉移份額時，處於已轉移資源狀態的起始節點會從目標節點收到資源轉移通知，資源轉移通知中包括該起始節點需繼續轉移的份額。處於未轉移資源狀態的起始節點會從目標節點收到資源轉移通知，其中包括該起始節點需轉移的份額。資源轉移通知中還可以包括導致資源轉移發生變化的原因。 如前所述，每個起始節點的需轉移份額、需繼續轉移的份額或退回的份額，由目標節點根據對轉移參數的更改和該起始節點的轉移狀態確定。 在起始節點上，步驟220，按照資源轉移通知向目標節點轉移資源。 當起始節點從目標節點收到資源轉移通知後，按照該資源轉移通知中需轉移的份額、或需繼續轉移的份額，向目標節點轉移資源。起始節點可以在經過用戶確認後進行資源轉移，也可以自動進行資源轉移，不做限定。 可見，本發明的實施例一中，在資源轉移的進行過程中或進行完畢後，可以通過目標節點上的轉移參數，由目標節點自動按照每個起始節點的轉移狀態，將與每個起始節點之間的資源轉移情況更正為與更新後的轉移參數相匹配，在應用於收付款時能夠避免人工計算和操作過程，提高錯誤糾正的效率，提升用戶的便利程度。 本發明的實施例二提出一種新的收付款的實現方法，對已經提交的收款操作，可以由收款用戶更改收款參數，並且按照更改後的收款參數和每個付款人是否付款的當前狀態，自動向付款方發起收款通知或向付款方退款，以使得更改後的支付結果匹配於更改後的收款參數，避免了收款用戶在原始收款參數錯誤的情況下，需要自行計算和手動更正當前收款的結果，以減少用戶的操作並提高錯誤糾正的效率，從而解決現有技術中存在的問題。 本發明的實施例二中，收款用戶的終端與支付伺服器、付款用戶的終端與支付伺服器通過網路可相互存取。其中，收款用戶的終端或付款用戶的終端可以是手機、平板電腦、PC、筆記型電腦等設備；支付伺服器可以是一個實體或邏輯伺服器，也可以是由兩個或兩個以上分擔不同職責的實體或邏輯伺服器、相互協同來實現本發明實施例二中伺服器的各項功能。 收款用戶與付款用戶在支付伺服器所運行的支付系統中具有各自的帳戶，收款用戶的終端和付款用戶的終端採用各自的帳戶登錄到該支付系統中，並通過其帳戶來進行款項的收付，收款用戶的帳戶為收款方，付款用戶的帳戶為付款方。 本發明的實施例二中，在收款用戶啟動一筆款項的收款操作後，支付系統向收款用戶提供對該款項的收款參數進行修改的功能。該收款操作的付款方可以是一個，也可以是兩個或兩個以上；該收款操作可以是正在進行中(即收款用戶已啟動收款操作，但尚未收到全部付款方的付款)，也可以是已經進行完畢(即已收到全部付款方的付款)；不做限定。另外，支付系統可以在收款用戶終端上安裝的用戶端中提供修改收款參數的功能，也可以在收款用戶終端對支付系統的存取頁面上提供該功能，同樣不做限定。 本發明的實施例二中，收付款的實現方法運行在收款方終端或支付伺服器上流程如圖3所示，運行在付款方終端上的流程如圖4所示。 在收款方終端或支付伺服器上，步驟310，接收對收款參數的更改。 本發明的實施例二中，收款方已經啟動收款操作，所收付的款項由收款方向至少一個付款方發起。在發起時，該收款操作具有確定的收款參數。對收款操作，收款參數通常包括款項總額、付款人數、每個付款方等等。在發起後，由於種種原因，收款用戶需要對一個到多個收款參數進行更改。 在本發明實施例二的第一種實現方式中，收款用戶通過其終端(即收款方終端)上安裝的用戶端來對已啟動收款操作的收款參數進行更改。這種實現方式中，用戶端和支付伺服器都可以保存已啟動收款操作的所有收款參數，根據實際應用場景的需要，既可以由用戶端、也可以由支付伺服器來採用更改後的收款參數對本收款操作的當前執行結果進行更正。在由用戶端進行更正的實現中，本方法運行在收款方終端上，由收款用戶在其終端的用戶端上給出對收款參數的更改指令，收款方終端從更改指令中得到更改後的收款參數。在由支付伺服器進行更正的實現中，本方法運行在支付伺服器上，由收款用戶在用戶端給出對收款參數的更改指令，收款方終端從更改指令中得到更改後的收款參數，封裝在收款參數更改請求中發送給支付伺服器。 在本發明實施例二的第二種實現方式中，收款方終端以web(全球資訊網)方式存取支付伺服器來進行收款參數的修改。這種實現方式中，本方法運行在支付伺服器上，由收款用戶在其終端上對收款參數進行更改，在收款用戶確認後收款方終端將更改後的收款參數封裝在收款參數更改請求中發送給支付伺服器。 除上述兩種實現方式外，收款方終端或支付伺服器也可以採用其他方式得到收款用戶對收款參數的更改，不再贅述。 在收款方終端或支付伺服器上，步驟320，按照更改後的收款參數和付款方的付款狀態，執行以下動作中的至少一個：通知至少一個付款方需支付的份額、向至少一個付款方退款。 在收款用戶啟動收款操作後，支付伺服器會按照當時的收款參數向付款方發起收款通知，告知付款方需要向收款方支付的份額。在收款用戶更改收款參數時，付款用戶可能已經按照之前的收款通知向收款方支付了更改前的份額，也可能尚未支付。在收款參數更改後，對已經支付的付款方，可能需要補繳差額、退回差額、或退回全部已支付的份額；對尚未支付的付款方，可能需要更改要支付的份額。因此，運行本方法的收款方終端或支付伺服器要按照當前各個付款方是否已支付的付款狀態、以及更改後的付款參數來確定對每個付款方是收款還是付款、以及收付款的份額。 本發明的實施例二中，收款用戶可以對一個到多個收款參數進行修改。以下舉例說明對不同的收款參數進行修改後的處理方法。 在第一個例子中，收款用戶在收款操作中指定款項總額，收款方終端或支付伺服器按照預定分配演算法，將款項總額分配給所有付款方。當收款用戶更改了款項總額後，收款方終端或支付伺服器將更改後的款型總額應用於預定分配演算法，得到每個付款方更改後的份額；對付款狀態為已支付的每個付款方，如果更改後的份額小於更改前的份額則退回多繳的份額，如果更改後的份額大於更改前的份額則通知該已支付的付款方需補繳的份額，如果更改後的份額與更改前的份額一致則不做處理；對付款狀態為未支付的每個付款方，按照更改後的份額通知該未支付的付款方需支付的份額。 在第二個例子中，收款用戶在更改收款參數時，增加了一個到多個付款方。付款方終端或支付伺服器按照對付款方的更改確定當前的付款方以及每個付款方更改後的份額，當前付款方為原先的付款方(更改前的付款方)與所增加的新付款方的集合，付款方的增加會導致一個到多個原先的付款方所支付的份額下降(根據如何分配款項總額確定)。因此付款方終端或支付伺服器對於每個付款狀態為已支付的付款方，當更改後的份額小於更改前的份額時退回多繳的份額；對每個付款狀態為未支付的原先的付款方，如果需支付的份額減少則按照更改後的份額通知該未支付的付款方，需支付的份額無變化時可以不通知也可以通知；對新增的付款方(付款狀態為未支付)，按照更改後的份額通知該其需支付的份額。 在第三個例子中，收款用戶在更改收款參數時，刪除了一個到多個付款方。付款方終端或支付伺服器按照對付款方的更改確定當前的付款方、被刪除的前付款方、以及每個付款方(即當前的付款方)更改後的份額，當前的付款方為未被刪除的付款方，前付款方為被刪除的付款方，付款方的減少會導致一個到多個付款方所支付的份額提高。付款方終端或支付伺服器對於每個付款狀態為已支付的付款方，當更改後的份額大於更改前的份額時通知該付款方需補繳的份額；對每個付款狀態為未支付的付款方，當更改後的份額大於更改前的份額時，按照更改後的份額通知該未支付的付款方需支付的份額；對每個前付款方，如果付款狀態為已支付則退回全部已支付份額，否則通知該前付款方無需支付。 在第四個例子中，收款用戶在更改收款參數時，更改了款項總額、付款方數目、和付款方中的一個到多個參數。付款方終端或支付伺服器按照對付款方的更改(包括對付款方數目和付款方的更改)確定當前的付款方(如果未刪除付款方)、或者確定當前的付款方和被刪除的前付款方(如果刪除了付款方)，當前的付款方包括未被刪除的付款方和新增的付款方，前付款方為被刪除的付款方。付款方終端或支付伺服器按照更改後的款項總額確定每個付款方更改後的份額。對每個付款狀態為已支付的付款方，如果更改後的份額小於更改前的份額則退回多繳的份額，如果更改後的份額大於更改前的份額則通知該付款方需補繳的份額；對每個付款狀態為未支付的付款方，如果是新增的付款方、或者更改後的份額與更改前的份額不同，則按照更改後的份額通知其需要支付的份額；對前付款方，如果已支付則退回已支付的份額，否則通知該前付款方無需支付。 在本方法運行在付款方終端上的實現方式中，收款方要通過支付伺服器來向付款方退款，具體過程請參見現有技術，不再贅述。通常，收款方終端按照更改後的收款參數和付款方的付款狀態，確定付款方需要補繳的份額、更新後需要支付的份額、和/或不需支付後，通過支付伺服器通知至少一個付款方需支付的份額、和/或請求支付伺服器向至少一個付款方退款；具體而言，收款方終端將付款方、需要告知付款方的內容提交給支付伺服器，由支付伺服器向付款方終端發送帶有上述內容的通知消息，如退款通知、更新的收款通知等等。在本方法運行在支付伺服器上的實現方式中，支付伺服器可直接進行由收款方向付款方退款、和通知付款方的步驟。 在付款方終端上，步驟410，接收退款通知或更新的收款通知，其中更新的收款通知中包括更新的需支付份額，退款通知中包括退回的部分或全部已支付份額；更新的需支付的份額或退回的份額根據對所收款款項的付款參數的更改和本付款方的付款狀態確定。 如前所述，付款方終端通常從支付伺服器接收退款通知或收款通知。支付伺服器在完成由收款方向付款方的退款(可能是部分已支付份額，也可能是全部已支付份額)後，將退款的金額、退款方在退款通知中告知付款方，退款通知中還可以攜帶退款理由等資訊。 如果付款方的付款狀態為未付款並且需要支付的份額發生變化，支付伺服器會向付款方終端發送帶有更新的需支付份額的收款通知。如果付款方的付款狀態為已支付並且更改後的份額大於更改前的份額，支付伺服器會向付款方終端發送帶有需補繳份額的收款通知。類似的，收款通知中還可以攜帶需支付的份額發生變化、或需補繳份額的理由等資訊。 在付款方終端上，步驟420，根據用戶的指令，按照接收的收款通知向收款方進行支付。 付款方終端將收到的退款通知或收款通知顯示給付款用戶。付款用戶可以針對收款通知進行向收款方付款的操作。當付款方終端收到付款用戶針對收款通知的付款指令後，根據收款通知向支付伺服器發起付款請求，支付伺服器按照收款通知中的份額進行付款方向收款方的轉帳。 可見，本發明的實施例二中，對已經提交的收款操作為收款用戶提供修改收款參數的功能，可以由收款用戶更改收款參數，依據更改後的收款參數和各個付款方的付款狀態，自動向付款方發起收款通知或向付款方退款，使得收款用戶在發生收款參數輸入錯誤時，不必自行計算和手動更正當前收款的結果，提高了錯誤糾正的效率，提升了用戶的便利程度。 在本發明的一個應用示例中，協力廠商支付平台的用戶端在AA收款功能中，為用戶提供了更改收款參數的入口，並能夠按照用戶更改後的收款參數，自動校正當前的收款結果，完成AA收款。在收款用戶終端的用戶端上，對已經啟動的AA收款訂單，收款用戶可以修改款項總額、付款人數和/或付款方。 以下以一個具體的例子進行說明。假設收款方以款項總額142元、付款人數為7發起一筆AA收款訂單；在發起訂單後，7位元付款方終端的用戶端收到需向收款方支付20.29元的收款通知。收款用戶發現對人數的統計有誤，在其用戶端上啟動對該筆訂單的收款參數進行修改的功能，一種用戶端介面如圖5所示。 設收款用戶將收款人數減少為6，並刪除了1位收款方，更改收款參數後的用戶端介面如圖6所示。收款方終端按照新的收款參數，確定當前的收款方(未被刪除的6位)和前收款方(被刪除的1位)，並確定每位當前收款方的份額為23.66元。 對本AA訂單中付款狀態為已支付的付款方，收款方終端通過協力廠商支付平台的支付伺服器向付款方終端發送收款通知，告知該付款用戶需要補繳3.37元差價。付款方終端收到該收款通知後，顯示給付款用戶，一種用戶端介面如圖7所示。在該介面上，付款用戶可以通過點擊“補交差價3.37”來通過支付伺服器向收款方支付3.37元。 對本AA訂單中付款狀態為未支付的付款方，收款方終端通過支付伺服器向付款方終端發送收款通知，告知該付款用戶需支付的份額為23.66元。付款方終端收到該收款通知後，顯示給付款用戶，一種用戶端介面如圖8所示。在該介面上，付款用戶可以通過點擊“支付23.66”來通過支付伺服器向收款方支付23.66元。 對被刪除的前付款方，如果該付款方已經支付，收款方終端請求支付伺服器向該前付款方退回已支付的全部份額，並通過支付伺服器向該前付款方終端發送退款通知。前付款方終端將退款通知的事由、退款金額顯示給前付款用戶。如果該付款方尚未支付，收款方終端通過支付伺服器向該前付款方終端發送通知，告知該前付款用戶無需進行該筆AA訂單的支付。 設收款用戶將收款人數增加為8，並增加了1位收款方，更改收款參數後的用戶端介面如圖9所示。收款方終端按照新的收款參數，確定當前的付款方為原先的7位加新增加的1位，並確定每位付款方的份額為17.75元。 對本AA訂單中付款狀態為已支付的每位付款方，收款方終端請求支付伺服器向該付款方退回2.54元，並通過協力廠商支付平台的支付伺服器向付款方終端發送退款通知，告知該付款用戶已退回2.54元差價。付款方終端收到該退款通知後，顯示給付款用戶，一種用戶端介面如圖10所示。 對本AA訂單中付款狀態為未支付的每個付款方(包括新增加的付款方)，收款方終端通過支付伺服器向付款方終端發送收款通知，告知該付款用戶需支付的份額為17.75元。 與上述流程實現對應，本發明的實施例還提供了一種應用在目標節點上的資源轉移的實現裝置、一種應用在起始節點上的資源轉移的實現裝置、一種應用在收款方終端或支付伺服器的收付款的實現裝置、和一種應用在付款方終端上的收付款的實現裝置。上述四種裝置均可以通過軟體實現，也可以通過硬體或者軟硬體結合的方式實現。以軟體實現為例，作為邏輯意義上的裝置，是通過所在設備的CPU(Central Process Unit，中央處理器)將對應的電腦程式指令讀取到記憶體中運行形成的。從硬體層面而言，除了圖11所示的CPU、記憶體以及非揮發性記憶體之外，上述裝置所在的設備通常還包括用於進行無線信號收發的晶片等其他硬體，和/或用於實現網路通訊功能的板卡等其他硬體。 圖12所示為本發明實施例提供的一種資源轉移的實現裝置，應用在資源轉移的目標節點上，所述裝置包括轉移參數接收單元和資源轉移更改單元，其中：轉移參數接收單元用於接收對轉移參數的更改；資源轉移更改單元用於按照更改後的轉移參數和起始節點的轉移狀態，執行以下動作中的至少一個：通知至少一個起始節點需轉移的資源份額、向至少一個起始節點退回部分或全部已轉移的資源。 可選的，所述對轉移參數的更改包括以下一項到多項：增加起始節點、刪除起始節點、更改資源轉移總額度；所述資源轉移更改單元具體用於：按照對起始節點的更改確定當前的起始節點、或當前的起始節點和被刪除的前起始節點，按照更改後的資源轉移總額度確定每個起始節點更改後的轉移份額；對每個已轉移資源的起始節點，當更改後的轉移份額小於更改前的轉移份額時退回多轉移的份額，當更改後的轉移份額大於更改前的轉移份額時通知所述已轉移資源的起始節點需繼續轉移的份額；對每個未轉移資源的起始節點，當更改後的轉移份額與更改前的轉移份額不同、或者所述未轉移資源的起始節點為新增起始節點時，按照更改後的轉移份額通知所述未轉移資源的起始節點需轉移的份額；所述裝置還包括：前起始節點更改單元，用於對前起始節點，如果已轉移資源則退回已轉移的份額，否則通知所述前起始節點無需進行資源轉移。 圖13所示為本發明實施例提供的一種資源轉移的實現裝置，應用在資源轉移的起始節點上，所述裝置包括退回或轉移通知接收單元、和資源轉移執行單元，其中：退回或轉移通知接收單元用於接收資源退回通知或資源轉移通知，所述資源轉移通知中包括更新的需轉移份額或需繼續轉移的份額，所述資源退回通知中包括退回的部分或全部已轉移的資源份額；所述需轉移份額、需繼續轉移的份額或退回的份額根據對所轉移資源的轉移參數的更改和本起始節點的轉移狀態確定； 資源轉移執行單元用於按照所述資源轉移通知向資源轉移的目標節點轉移資源。 圖14所示為本發明實施例提供的一種收付款的實現裝置，包括收款參數接收單元和收付款更改單元，其中：收款參數接收單元用於接收對收款參數的更改；收付款更改單元用於按照更改後的收款參數和付款方的付款狀態，執行以下動作中的至少一個：通知至少一個付款方需支付的份額、向至少一個付款方退款。 可選的，所述對收款參數的更改包括：更改款項總額，所述款項總額按照預定分配演算法分配給每個付款方；所述收付款更改單元具體用於：採用更改後的款項總額按照所述預定分配演算法確定每個付款方更改後的份額；對每個已支付的付款方，當更改後的份額小於更改前的份額時退回多繳的份額，當更改後的份額大於更改前的份額時通知所述已支付的付款方需補繳的份額；對每個未支付的付款方，按照更改後的份額通知所述未支付的付款方需支付的份額。 可選的，所述對收款參數的更改包括：增加付款方；所述收付款更改單元具體用於：按照對付款方的更改確定當前的付款方以及每個付款方更改後的份額；對每個已支付的付款方，當更改後的份額小於更改前的份額時退回多繳的份額；對至少一個未支付的付款方，按照更改後的份額通知所述未支付的付款方需支付的份額。 可選的，所述對收款參數的更改包括：刪除付款方；所述收付款更改單元具體用於：按照對付款方的更改確定當前的付款方、被刪除的前付款方、以及每個付款方更改後的份額；對每個已支付的付款方，當更改後的份額大於更改前的份額時通知所述已支付的付款方需補繳的份額；對每個未支付的付款方，當更改後的份額大於更改前的份額時按照更改後的份額通知所述未支付的付款方需支付的份額；所述裝置還包括：前付款方更改單元，用於對前付款方，如果已支付則退回已支付份額，否則通知所述前付款方無需支付。 可選的，所述對收款參數的更改包括以下一項到多項：增加付款方、刪除付款方、更改款項總額；所述收付款更改單元具體用於：按照對付款方的更改確定當前的付款方、或當前的付款方和被刪除的前付款方，按照更改後的款項總額確定每個付款方更改後的份額；對每個已支付的付款方，當更改後的份額小於更改前的份額時退回多繳的份額，當更改後的份額大於更改前的份額時通知所述已支付的付款方需補繳的份額；對每個未支付的付款方，當更改後的份額與更改前的份額不同、或者所述未支付的付款方為新增付款方時，按照更改後的份額通知所述未支付的付款方需支付的份額；所述裝置還包括：前付款方更改單元，用於對前付款方，如果已支付則退回已支付的份額，否則通知所述前付款方無需支付。 可選的，所述裝置應用在收款方終端上；所述收款參數接收單元具體用於：接收用戶對收款參數的更改指令；所述收付款更改單元具體用於：按照更改後的收款參數和付款方的付款狀態，執行以下動作中的至少一個：通過支付伺服器通知至少一個付款方需支付的份額、請求支付伺服器向至少一個付款方退款。 可選的，所述裝置應用在支付伺服器上；所述收款參數接收單元具體用於：接收來自收款方終端的收款參數更改請求。 圖15所示為本發明實施例提供的一種收付款的實現裝置，應用在付款方終端上，所述裝置包括收退款通知接收單元和收款支付單元，其中：收退款通知接收單元用於接收退款通知或收款通知，所述收款通知中包括更新的需支付份額或需補繳的份額，所述退款通知中包括退回的部分或全部已支付份額；所述需支付份額、需補繳的份額或退回的份額根據對所收款款項的付款參數的更改和本付款方的付款狀態確定；收款支付單元用於根據用戶的指令，按照所述收款通知向收款方進行支付。 以上所述僅為本發明的較佳實施例而已，並不用以限制本發明，凡在本發明的精神和原則之內，所做的任何修改、等同替換、改進等，均應包含在本發明保護的範圍之內。 在一個典型的配置中，計算設備包括一個或多個處理器(CPU)、輸入/輸出介面、網路介面和記憶體。 記憶體可能包括電腦可讀介質中的非永久性記憶體，隨機存取記憶體(RAM)和/或非揮發性記憶體等形式，如唯讀記憶體(ROM)或快閃記憶體(flash RAM)。記憶體是電腦可讀介質的示例。 電腦可讀介質包括永久性和非永久性、可移動和非可移動媒體可以由任何方法或技術來實現資訊儲存。資訊可以是電腦可讀指令、資料結構、程式的模組或其他資料。電腦的儲存介質的例子包括，但不限於相變記憶體(PRAM)、靜態隨機存取記憶體(SRAM)、動態隨機存取記憶體(DRAM)、其他類型的隨機存取記憶體(RAM)、唯讀記憶體(ROM)、電可擦除可程式設計唯讀記憶體 (EEPROM)、快閃記憶體或其他記憶體技術、唯讀光碟唯讀記憶體(CD-ROM)、數位多功能光碟(DVD)或其他光學儲存、磁盒式磁帶，磁帶磁磁片儲存或其他磁性存放裝置或任何其他非傳輸介質，可用於儲存可以被計算設備存取的資訊。按照本文中的界定，電腦可讀介質不包括暫存電腦可讀媒體(transitory media)，如調變的資料信號和載波。 還需要說明的是，術語“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、商品或者設備不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、商品或者設備所固有的要素。在沒有更多限制的情況下，由語句“包括一個……”限定的要素，並不排除在包括所述要素的過程、方法、商品或者設備中還存在另外的相同要素。 本領域技術人員應明白，本發明的實施例可提供為方法、系統或電腦程式產品。因此，本發明可採用完全硬體實施例、完全軟體實施例或結合軟體和硬體方面的實施例的形式。而且，本發明可採用在一個或多個其中包含有電腦可用程式碼的電腦可用儲存介質(包括但不限於磁碟記憶體、CD-ROM、光學記憶體等)上實施的電腦程式產品的形式。In various transactions carried out through the network, the progress of the transaction is often accompanied by the flow of resources between network nodes. In a transaction, resources flow from one or more start nodes to a target node. The target node determines the transfer share of each start node according to the total amount of resource transfer of the transaction, and then sends resource transfer notifications to each start node. , The resource transfer notification carries the transfer share that the initiating node needs to transfer to the target node. The initiating node transfers its own resources to the target node according to the transfer share in the resource transfer notification. The first embodiment of the present invention proposes a resource transfer implementation method for the above transaction, which can change the transfer parameters on the target node during and after the transaction, so that the result of the resource transfer is automatically corrected to match the changed The transfer parameters can avoid manual calculation and operation process when applied to collection and payment, so as to solve the problems in the prior art. In the first embodiment of the present invention, the start node and the target node can access each other through a network. The start node and target node can be any device with computing and storage capabilities, such as mobile phones, tablets, PCs (Personal Computers), notebook computers, servers, etc.; they can also be run on two or two devices. The logical nodes of more than one device implement various functions of the start node or the target node in the embodiment of the present invention. In the first embodiment of the present invention, the process of implementing the resource transfer method applied to the target node is shown in Fig. 1, and the process applied to the starting node is shown in Fig. 2. On the target node, step 110, receiving changes to the transfer parameters. After the transaction is started, the target node and the start node can transfer resources according to the initial transfer parameters. During the transaction or after the transaction, that is, during the resource transfer or after the resource transfer, the transfer parameters on the target node can be changed. The changes to the transfer parameters can be done manually or automatically by other nodes in the network that have management permissions, without limitation. In a transaction involving resource transfer, the transfer parameters can usually include the total amount of resource transfer, the number of starting nodes, each starting node, and so on. On the target node, step 120, according to the changed transfer parameters and the transfer status of the initiating node, perform at least one of the following actions: notifying at least one initiating node of the resource share to be transferred, and returning part to at least one initiating node Or all transferred resources. As mentioned earlier, after the transaction is initiated, the target node will determine the transfer share of each initiating node according to the initial transfer parameters, and notify each initiating node to transfer resources. When the target node receives the change to the transfer parameters, the transaction is already in progress or has been completed. The transfer status of the starting node includes two types: transferred resources (resource transfer has been completed according to the transfer share determined by the initial transfer parameters), Or the resource has not been transferred (the resource has not been transferred yet). After the target node receives the changed transfer parameters, it determines the changed transfer share of each initiating node according to the changed transfer parameters. According to the transfer status of each initiating node, the transferred resources exceed the changed share. The starting node returns part of the over-transferred resources (the difference between the transfer shares of the starting node before and after the change), and informs that the transferred resources are insufficient. After the change, the starting node of the share needs to continue to transfer the shares (the same before and after the change) The difference between the transfer shares of the starting node), and notify the starting node that has not transferred resources its transfer shares (transfer shares determined according to the transfer parameters after the change). In one implementation, the transfer parameters that can be changed include one or more of adding a starting node, deleting a starting node, and changing the total amount of resource transfer. After receiving the change to the transfer parameter, the target node determines the current start node, or the current start node, and the previous start node that was deleted according to the change to the start node. Specifically, if the original start node is not deleted, the current start node is determined; if the original start node is deleted, the current start node and the deleted previous start node are determined. The target node determines the changed transfer share of each start node (that is, the current start node) according to the total amount of resource transfer after the change. For the starting node of each transferred resource, when the transferred share after the change is less than the transferred share before the change, the target node returns the transferred share to the start node; when the changed transfer share is greater than the transferred share before the change At the time, the target node informs the starting node of the share to be transferred. For each start node of untransferred resources, when the changed transfer share is different from the transfer share before the change, or the start node is a new start node, the start node is notified according to the changed transfer share The share to be transferred. For the former start node, if the resource has been transferred, the target node returns the transferred share to the former start node, otherwise the target node informs the former start node that no resource transfer is required. After the target node returns part or all of the transferred resources to the initiating node, the target node can send a resource return notification to the initiating node, and inform the initiating node of the state of the resources that have been returned. On the starting node, step 210, receive a resource return notification or a resource transfer notification. When the transferred share after the change is less than the transfer share before the change, or when the start node is deleted to become the previous start node, the start node in the transferred resource state will receive a resource return notification from the target node. The resource return notification includes the returned quota, and may also include the reason that caused the resource return (such as changes to transfer parameters). When the transferred shares after the change are more than the transferred shares before the change, the starting node in the transferred resource state will receive a resource transfer notification from the target node, and the resource transfer notification includes the shares that the starting node needs to continue to transfer. The start node in the state of untransferred resources will receive a resource transfer notification from the target node, which includes the share to be transferred by the start node. The resource transfer notification may also include the reason that caused the resource transfer to change. As mentioned earlier, the share to be transferred, the share to be transferred or the share to be returned for each initiating node is determined by the target node according to the changes to the transfer parameters and the transfer status of the initiating node. On the start node, step 220, transfer resources to the target node according to the resource transfer notification. When the initiating node receives a resource transfer notification from the target node, it transfers resources to the target node according to the share to be transferred or the share to be transferred in the resource transfer notification. The starting node can perform resource transfer after user confirmation, or it can automatically perform resource transfer, which is not limited. It can be seen that, in the first embodiment of the present invention, during or after the resource transfer, the transfer parameters on the target node can be used to allow the target node to automatically follow the transfer status of each start node, and the target node will be connected to each start node. The resource transfer situation between the starting nodes is corrected to match the updated transfer parameters, which can avoid manual calculation and operation when applied to payment and collection, improve the efficiency of error correction, and enhance the convenience of users. The second embodiment of the present invention proposes a new method for implementing collection and payment. For the collection operation that has been submitted, the collection user can change the collection parameters, and according to the modified collection parameters and whether each payer pays In the current state, the payment notification is automatically initiated to the payer or the payer is refunded so that the changed payment result matches the changed payment parameters, which avoids the need for the receiving user when the original payment parameters are incorrect. Calculate and manually correct the result of the current collection by oneself, so as to reduce the user's operation and improve the efficiency of error correction, thereby solving the problems in the prior art. In the second embodiment of the present invention, the terminal of the receiving user and the payment server, and the terminal of the paying user and the payment server can mutually access through the network. Among them, the terminal of the receiving user or the terminal of the paying user can be a mobile phone, tablet, PC, notebook computer, etc.; the payment server can be a physical or logical server, or it can be shared by two or more Entity or logical servers with different responsibilities cooperate with each other to realize the functions of the server in the second embodiment of the present invention. The receiving user and the paying user have their own accounts in the payment system running on the payment server, and the receiving user’s terminal and the paying user’s terminal use their respective accounts to log in to the payment system, and make payments through their accounts. In receipt and payment, the account of the receiving user is the payee, and the account of the paying user is the payer. In the second embodiment of the present invention, after the receiving user initiates the payment operation of a sum of money, the payment system provides the receiving user with the function of modifying the payment parameters of the payment. The payer of the collection operation can be one, two or more; the collection operation can be in progress (that is, the receiving user has initiated the collection operation, but has not yet received all payments from the payer ), it can also be completed (that is, all payments from the payer have been received); there is no limit. In addition, the payment system may provide the function of modifying the payment parameters in the user terminal installed on the receiving user terminal, or may provide the function on the access page of the payment system of the receiving user terminal, which is also not limited. In the second embodiment of the present invention, the flow of the method for implementing collection and payment running on the payee terminal or payment server is shown in Figure 3, and the process running on the payer terminal is shown in Figure 4. On the payee terminal or payment server, step 310, receive changes to the payment parameters. In the second embodiment of the present invention, the payee has initiated the collection operation, and the received payment is initiated by the payee to at least one payer. At the time of initiation, the collection operation has certain collection parameters. For collection operations, the collection parameters usually include the total amount, the number of payers, each payer, and so on. After the initiation, due to various reasons, the receiving user needs to change one or more receiving parameters. In the first implementation of the second embodiment of the present invention, the payee user modifies the payment parameters of the payment collection operation that has been initiated through the client terminal installed on his terminal (ie, the payee terminal). In this implementation method, both the client and the payment server can save all the payment parameters that have started the payment operation. According to the needs of the actual application scenario, either the user side or the payment server can adopt the modified The payment parameters correct the current execution result of this payment operation. In the implementation of correction by the user side, this method runs on the payee terminal, and the payee user gives an instruction to modify the payment parameters on the user end of the terminal, and the payee terminal obtains from the change instruction The changed payment parameters. In the implementation of correction by the payment server, this method runs on the payment server, and the payee user gives an instruction to change the payment parameters on the user side, and the payee terminal obtains the changed payment from the change instruction. Payment parameters are encapsulated in the payment parameter change request and sent to the payment server. In the second implementation of the second embodiment of the present invention, the payee terminal accesses the payment server in a web (Worldwide Information Network) mode to modify the payment parameters. In this implementation, the method runs on the payment server, and the receiving user changes the payment parameters on his terminal. After the receiving user confirms the payment, the payee terminal encapsulates the changed payment parameters in the payment server. The payment parameter change request is sent to the payment server. In addition to the above two implementation methods, the payee terminal or payment server can also use other methods to obtain the payee user's changes to the payment parameters, so I will not repeat them. On the payee terminal or payment server, step 320, according to the changed payout parameters and the payer’s payment status, perform at least one of the following actions: notify at least one payer of the share to be paid, and pay at least one Party refunds. After the receiving user initiates the payment operation, the payment server will initiate a payment notification to the payer according to the payment parameters at the time, and inform the payer of the share that needs to be paid to the payee. When the receiving user changes the payment parameters, the paying user may have paid the payee the share before the change according to the previous payment notification, or may not have paid yet. After the payment parameters are changed, the payer who has already paid may need to make up the difference, refund the difference, or return the entire paid share; for the payer who has not paid, it may need to change the share to be paid. Therefore, the payee terminal or payment server running this method must determine whether each payer is to receive or pay, as well as the payment status, according to the current payment status of whether each payer has paid, and the changed payment parameters. Share. In the second embodiment of the present invention, the receiving user can modify one or more receiving parameters. The following examples illustrate how to modify different payment parameters. In the first example, the receiving user specifies the total amount of money in the payment operation, and the payee terminal or payment server distributes the total amount to all payers according to a predetermined allocation algorithm. When the payee user changes the total amount of the payment, the payee terminal or payment server applies the changed amount to the predetermined allocation algorithm to obtain the changed share of each payer; for each payment status of paid If the changed share is less than the share before the change, the overpaid share will be returned. If the changed share is greater than the share before the change, the paid payer will be notified of the paid share. If the changed share is If it is consistent with the share before the change, it will not be processed; for each payer whose payment status is unpaid, the unpaid payer will be notified of the share to be paid according to the changed share. In the second example, when the receiving user changes the receiving parameters, one or more payers are added. The payer’s terminal or payment server determines the current payer and the changed share of each payer according to the change to the payer. The current payer is the original payer (the payer before the change) and the new payer added The increase of the payer will lead to a decrease in the share paid by one or more original payers (determined according to how the total payment is distributed). Therefore, for each payer whose payment status is paid, the payer’s terminal or payment server refunds the overpaid share when the changed share is less than the share before the change; for each original payer whose payment status is unpaid If the share to be paid decreases, the unpaid payer will be notified according to the changed share. If there is no change in the share to be paid, the payer can be notified without notice; for the newly added payer (the payment status is unpaid), The changed share is notified of the share to be paid. In the third example, when the receiving user changed the receiving parameters, he deleted one or more payers. The payer’s terminal or payment server determines the current payer, the deleted previous payer, and the changed share of each payer (that is, the current payer) according to the change to the payer. The current payer is not The deleted payer, the previous payer is the deleted payer, and the decrease of the payer will lead to an increase in the share paid by one or more payers. For each payer whose payment status is paid, the payer’s terminal or payment server informs the payer of the share to be paid when the changed share is greater than the share before the change; for each payment that has an unpaid payment status When the changed share is greater than the share before the change, the unpaid payer shall be notified of the share to be paid according to the changed share; for each former payer, if the payment status is paid, all the paid shares will be returned , Otherwise notify the former payer that there is no need to pay. In the fourth example, when the receiving user changed the receiving parameters, he changed one or more of the total amount, the number of payers, and the payers. The payer terminal or payment server determines the current payer (if the payer is not deleted) according to the changes to the payer (including changes to the number of payers and the payer), or determines the current payer and the deleted previous payment Party (if the payer is deleted), the current payer includes the payer that has not been deleted and the newly added payer, and the previous payer is the deleted payer. The payer’s terminal or payment server determines the changed share of each payer based on the changed total amount. For each payer whose payment status is paid, if the changed share is less than the share before the change, the overpaid share will be refunded; if the changed share is greater than the share before the change, the payer will be notified of the additional share to be paid; For each payer whose payment status is unpaid, if it is a new payer or the changed share is different from the share before the change, the share to be paid shall be notified according to the changed share; for the former payer, If paid, the paid share will be returned, otherwise the former payer will be notified that there is no need to pay. In the implementation of this method running on the payer's terminal, the payee needs to refund the payer through the payment server. For the specific process, please refer to the prior art and will not be repeated. Generally, the payee terminal determines the share to be paid by the payer, the share to be paid after the update, and/or no payment is required according to the changed payment parameters and the payment status of the payer, and the payment server informs at least The share that a payer needs to pay, and/or request the payment server to refund at least one payer; specifically, the payee terminal submits the payer and the content that needs to be notified to the payment server, and the payment server The device sends a notification message with the above content to the payer terminal, such as a refund notification, an updated payment notification, and so on. In the implementation of the method running on the payment server, the payment server can directly perform the steps of refunding the payer from the payer and notifying the payer. On the payer terminal, in step 410, a refund notification or an updated collection notification is received, where the updated collection notification includes the updated share to be paid, and the refund notification includes the returned part or all of the paid share; the updated The share to be paid or the share to be returned is determined based on the change in the payment parameters of the received payment and the payment status of the payer. As mentioned above, the payer terminal usually receives a refund notification or a payment notification from the payment server. After the payment server completes the refund from the payee to the payer (may be part of the paid share or all of the paid share), the payment server informs the payer of the refund amount and the refunding party in the refund notice. The refund notification can also carry information such as the reason for the refund. If the payment status of the payer is unpaid and the share to be paid changes, the payment server will send a payment notification with the updated share to be paid to the payer’s terminal. If the payment status of the payer is paid and the changed share is greater than the share before the change, the payment server will send a payment notification with the required share to the payer terminal. Similarly, the collection notice can also carry information such as the change in the share to be paid or the reason for the payment of the share. On the payer's terminal, step 420, according to the user's instruction, pay the payee according to the received payment notification. The payer’s terminal displays the received refund notification or payment notification to the paying user. The paying user can perform payment operations to the payee in response to the payment notification. When the payer terminal receives the payment instruction from the paying user for the payment notification, it initiates a payment request to the payment server according to the payment notification, and the payment server transfers the payment to the recipient according to the share in the payment notification. It can be seen that in the second embodiment of the present invention, the receiving user is provided with the function of modifying the payment parameters for the submitted payment operation. The receiving user can change the payment parameters based on the changed payment parameters and each payer. Payment status, automatically initiate a payment notification to the payer or refund to the payer, so that the receiving user does not have to calculate and manually correct the result of the current payment when a payment parameter input error occurs, which improves the efficiency of error correction , Improve the convenience of users. In an application example of the present invention, the user terminal of the third-party payment platform provides the user with an entrance to change the payment parameters in the AA payment function, and can automatically correct the current payment according to the changed payment parameters of the user. As a result, complete AA collection. On the user side of the receiving user terminal, the receiving user can modify the total amount, the number of payers, and/or the payer for the AA receiving order that has been activated. The following is a specific example for explanation. Assume that the payee initiates an AA collection order with a total payment of 142 yuan and the number of payers is 7. After the order is initiated, the user terminal of the 7-bit payer terminal receives a payment notification that requires a payment of 20.29 yuan to the payee. The receiving user finds that the statistics on the number of people is incorrect, and activates the function of modifying the payment parameters of the order on the user terminal. A user terminal interface is shown in Figure 5. Assuming that the receiving user reduces the number of payees to 6, and deletes one payee, the user interface after changing the receiving parameters is shown in Figure 6. The payee terminal determines the current payee (6 digits that have not been deleted) and the previous payee (1 digit that has been deleted) according to the new payment parameters, and determines that each current payee's share is 23.66 yuan. For the payer whose payment status is paid in this AA order, the payee terminal sends a payment notification to the payer terminal through the payment server of the third-party payment platform to inform the payer that the payer needs to pay the difference of 3.37 yuan. After receiving the payment notification, the payer terminal displays it to the paying user. A user terminal interface is shown in Figure 7. On this interface, the paying user can pay 3.37 yuan to the payee through the payment server by clicking "make up the difference 3.37". For the payer whose payment status is unpaid in this AA order, the payee terminal sends a payment notification to the payer terminal through the payment server, informing the payer that the payable share is 23.66 yuan. After receiving the payment notification, the payer terminal displays it to the paying user. A user terminal interface is shown in Figure 8. On this interface, the paying user can pay 23.66 yuan to the payee through the payment server by clicking "Pay 23.66". For the deleted former payer, if the payer has already paid, the payee terminal requests the payment server to return all the paid shares to the former payer, and sends a refund notification to the former payer terminal through the payment server . The former payer’s terminal displays the reason for the refund notification and the refund amount to the prepay user. If the payer has not paid yet, the payee terminal sends a notification to the prepayer terminal through the payment server, informing the prepay user that there is no need to pay for the AA order. It is assumed that the receiving user increases the number of payees to 8, and adds one payee. The user terminal interface after changing the receiving parameters is shown in Figure 9. According to the new payment parameters, the payee terminal determines that the current payer is the original 7 digits plus one newly added digit, and determines that each payer’s share is 17.75 yuan. For each payer whose payment status is paid in this AA order, the payee terminal requests the payment server to return 2.54 yuan to the payer, and sends a refund notification to the payer terminal through the payment server of the third-party payment platform. Inform the paying user that the difference of 2.54 yuan has been refunded. After receiving the refund notification, the payer terminal displays it to the paying user. A user terminal interface is shown in Figure 10. For each payer whose payment status is unpaid in this AA order (including newly added payers), the payee terminal sends a payment notification to the payer terminal through the payment server, informing the payer that the payable share is 17.75 yuan. Corresponding to the implementation of the above process, the embodiment of the present invention also provides a device for implementing resource transfer applied on the target node, a device for implementing resource transfer applied on the initiating node, and a device applied to the payee terminal or payment A device for realizing receipt and payment of a server, and a device for realizing receipt and payment applied to a payer terminal. The above four devices can all be implemented by software, or by hardware or a combination of software and hardware. Taking software implementation as an example, as a logical device, it is formed by reading the corresponding computer program instructions into the memory by the CPU (Central Process Unit) of the device where it is located. From a hardware perspective, in addition to the CPU, memory, and non-volatile memory shown in Figure 11, the equipment where the above-mentioned devices are located usually also includes other hardware such as chips for wireless signal transmission and reception, and/or Other hardware such as boards used to realize network communication functions. FIG. 12 shows a device for implementing resource transfer according to an embodiment of the present invention, which is applied to the target node of resource transfer. The device includes a transfer parameter receiving unit and a resource transfer modification unit, wherein: the transfer parameter receiving unit is used to receive Changes to the transfer parameters; the resource transfer modification unit is used to perform at least one of the following actions according to the changed transfer parameters and the transfer state of the starting node: notifying at least one starting node of the resource share to be transferred, to at least one starting node The originating node returns part or all of the transferred resources. Optionally, the changes to the transfer parameters include one or more of the following: adding a starting node, deleting a starting node, and changing the total amount of resource transfer; the resource transfer changing unit is specifically used to: Change to determine the current start node, or the current start node and the previous start node that was deleted, and determine the transfer share of each start node after the change according to the total amount of resource transfer after the change; for each transferred resource The starting node, when the changed transfer share is less than the transfer share before the change, returns the multi-transferred share, and when the changed transfer share is greater than the transfer share before the change, it notifies the starting node of the transferred resource to continue the transfer Share; for each start node of the untransferred resource, when the changed transfer share is different from the transfer share before the change, or the start node of the untransferred resource is a new start node, follow the changed transfer The share notifies the start node of the untransferred resource of the share to be transferred; the device further includes: a former start node changing unit for returning the transferred share to the former start node if the resource has been transferred, otherwise it is notified The former start node does not need to transfer resources. FIG. 13 shows a device for implementing resource transfer provided by an embodiment of the present invention, which is applied to the start node of resource transfer. The device includes a return or transfer notification receiving unit and a resource transfer execution unit, wherein: return or transfer The notification receiving unit is configured to receive a resource return notification or a resource transfer notification, the resource transfer notification including the updated share to be transferred or the share to be transferred, and the resource return notification includes the returned part or all of the transferred resource share The share to be transferred, the share to be transferred or the share to be returned are determined according to the change of the transfer parameter of the transferred resource and the transfer status of the starting node; the resource transfer execution unit is used to send the resource to the resource according to the resource transfer notification The target node of the transfer transfers resources. Figure 14 shows a collection and payment implementation device provided by an embodiment of the present invention, including a collection parameter receiving unit and a collection and payment modification unit, where: the collection parameter receiving unit is used to receive changes to collection parameters; The unit is used to perform at least one of the following actions according to the changed payment parameters and the payment status of the payer: notifying at least one payer of the share to be paid, and refunding at least one payer. Optionally, the change to the payment parameters includes: changing the total payment, which is allocated to each payer according to a predetermined allocation algorithm; the payment and receipt modification unit is specifically used to: adopt the changed total payment Determine the changed share of each payer according to the predetermined allocation algorithm; for each paid payer, when the changed share is less than the share before the change, the overpaid share will be refunded, and when the changed share is greater than the changed share The former share shall be notified to the paid payer of the share to be paid; for each unpaid payer, the share to be paid by the unpaid payer shall be notified according to the changed share. Optionally, the change to the payment parameters includes: adding a payer; the payment change unit is specifically used to: determine the current payer and the changed share of each payer according to the change to the payer; For each paid payer, when the changed share is less than the share before the change, the overpaid share will be returned; for at least one payer that has not paid, the unpaid payer shall be notified of the payment according to the changed share Share. Optionally, the change to the payment parameters includes: deleting the payer; the payment change unit is specifically used to determine the current payer, the deleted previous payer, and each The payer’s changed share; for each paid payer, when the changed share is greater than the pre-change share, the paid payer is notified of the paid share; for each unpaid payer, When the changed share is greater than the share before the change, the share to be paid by the unpaid payer will be notified according to the changed share; the device also includes: the former payer changing unit, which is used to pay the former payer if If the payment is made, the paid share will be returned, otherwise the former payer will be notified that there is no need to pay. Optionally, the changes to the payment parameters include one or more of the following: add a payer, delete a payer, change the total amount of the payment; the payment change unit is specifically used to: determine the current payment based on the change to the payer The payer, or the current payer and the deleted former payer, shall determine the changed share of each payer according to the total amount of the changed payment; for each payer that has been paid, when the changed share is less than that before the change The overpaid share is returned when the share is changed. When the changed share is greater than the share before the change, the paid payer will be notified of the paid share; for each unpaid payer, when the changed share is the same as before the change When the share of the unpaid payer is different, or the unpaid payer is a new payer, the unpaid payer is notified of the share to be paid according to the changed share; the device also includes: the former payer changing unit, For the former payer, if the payment has been made, the paid share shall be returned, otherwise the said former payer shall be notified that there is no need to pay. Optionally, the device is applied to the payee terminal; the payment parameter receiving unit is specifically used to: receive a user's instruction to change the payment parameters; the payment change unit is specifically used to: follow the modified The payment parameters and the payment status of the payer perform at least one of the following actions: notify at least one payer of the share to be paid through the payment server, and request the payment server to refund at least one payer. Optionally, the device is applied to a payment server; the payment parameter receiving unit is specifically configured to: receive a payment parameter change request from the payee terminal. 15 shows a collection and payment implementation device provided by an embodiment of the present invention, which is applied to a payer's terminal. The device includes a collection and refund notification receiving unit and a collection payment unit, wherein: the collection and refund notification receiving unit is used When receiving a refund notice or a payment notification, the payment notification includes the updated share to be paid or the share to be paid, and the refund notice includes a part or all of the paid share; the share to be paid , The share to be repaid or the share to be returned is determined according to the changes to the payment parameters of the received payment and the payment status of the payer; the collection payment unit is used to send the payment to the collection in accordance with the user's instruction Party to pay. The above are only preferred embodiments of the present invention and are not intended to limit the present invention. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention shall be included in the present invention Within the scope of protection. In a typical configuration, the computing device includes one or more processors (CPU), input/output interfaces, network interfaces, and memory. Memory may include non-permanent memory in computer-readable media, random access memory (RAM) and/or non-volatile memory, such as read-only memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media. Computer-readable media includes permanent and non-permanent, removable and non-removable media, and information storage can be realized by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), and other types of random access memory (RAM) , Read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, read-only CD-ROM (CD-ROM), digital multi-function Optical discs (DVD) or other optical storage, magnetic cassettes, magnetic tape storage or other magnetic storage devices, or any other non-transmission media, can be used to store information that can be accessed by computing devices. According to the definition in this article, computer-readable media does not include transitory media, such as modulated data signals and carrier waves. It should also be noted that the terms "include", "include" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, product or equipment including a series of elements not only includes those elements, but also includes Other elements that are not explicitly listed, or they also include elements inherent to such processes, methods, commodities, or equipment. If there are no more restrictions, the element defined by the sentence "including a..." does not exclude the existence of other identical elements in the process, method, commodity, or equipment that includes the element. "A person skilled in the art should understand that the embodiments of the present invention can be provided as a method, a system, or a computer program product. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware. Moreover, the present invention can be in the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk memory, CD-ROM, optical memory, etc.) containing computer-usable program codes. .
