在通過網路進行的各種事務中，事務的進行常常伴隨著資源在網路節點間的流動。在一種事務中，由資源由一個到多個起始節點流向一個目標節點，目標節點按照事務的資源轉移總額度，確定各個起始節點的轉移份額，然後分別向各個起始節點發送資源轉移通知，在資源轉移通知中攜帶有該起始節點需要轉移給目標節點的轉移份額。起始節點根據資源轉移通知中的轉移份額將自身的資源轉移至目標節點。 本發明的實施例一針對上述事務提出一種資源轉移的實現方法，能夠在事務的進行過程中和進行完畢後，在目標節點上通過更改轉移參數，使得資源轉移的結果自動校正為匹配於更改後的轉移參數，在應用於收付款時能夠避免人工計算和操作過程，以解決現有技術中存在的問題。 本發明的實施例一中，起始節點和目標節點之間通過網路可以相互存取。起始節點和目標節點可以是任何具有計算和儲存能力的設備，如手機、平板電腦、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 the various transactions conducted through the network, the progress of the transaction is often accompanied by the flow of resources between the network nodes. In a transaction, resources flow from one to multiple 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 separately , The resource transfer notification carries the transfer share that the starting node needs to transfer to the target node. The starting node transfers its own resources to the target node according to the transfer share in the resource transfer notification. Embodiment 1 of the present invention proposes a resource transfer implementation method for the above transaction, which can change the transfer parameter on the target node during and after the transaction, so that the result of resource transfer is automatically corrected to match the change The transfer parameters of the software can avoid manual calculation and operation process when applied to the 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 the network. The starting node and the target node can be any devices with computing and storage capabilities, such as mobile phones, tablet computers, PCs (Personal Computers), notebook computers, servers, etc .; they can also be run by two or two Logic nodes of more than one device to 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 flow of the resource transfer implementation method applied to the target node is shown in FIG. 1, and the flow applied to the starting node is shown in FIG. 2. On the target node, step 110, receive changes to the transfer parameters. After the transaction is started, the target node and the starting node can transfer resources according to the initial transfer parameters. During the course of the transaction or after the end of the transaction, that is, during the resource transfer or after the resource transfer, the transfer parameters on the target node can be changed. The change of the transfer parameters can be performed manually or automatically by other nodes in the network with management permission, without limitation. In transactions 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 start node, perform at least one of the following actions: notify at least one start node of the resource share to be transferred, and return the portion to at least one start node Or all transferred resources. As mentioned above, after the transaction is started, the target node will determine the transfer share of each starting node according to the initial transfer parameters, and notify each starting node to transfer resources. When the target node receives changes 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). After receiving the changed transfer parameters, the target node determines the changed transfer share of each start node according to the changed transfer parameters. According to the transfer status of each start node, the transferred resources exceed the changed share The starting node returns part of the resources transferred in excess (the difference between the share transferred by the starting node before and after the change), notifying that the transferred resources are insufficient and the starting node of the changed share needs to continue to transfer the share (before and after the change) The difference of the transfer share of the starting node), notifying the starting node of the non-transferred resource its transfer share (the transfer share determined according to the changed transfer parameters). In one implementation, the transfer parameters that can be changed include one or more of adding the starting node, deleting the 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 deleted previous start node 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 starting node (that is, the current starting node) according to the changed total amount of resource transfer. For the starting node of each transferred resource, when the changed transfer share is less than the transfer share before the change, the target node returns the multi-transfer share to the starting node; when the changed transfer share is greater than the transfer share before the change At this time, the target node informs the starting node of the shares that need to be transferred. For the start node of each untransferred resource, when the changed transfer share is different from the transfer share before the change, or the start node is a newly added start node, the start node is notified according to the changed transfer share The share to be transferred. For the previous starting node, if the resource has been transferred, the target node returns the transferred share to the previous starting node, otherwise the target node notifies the previous starting node that no resource transfer is required. After the target node returns some or all of the transferred resources to the starting node, the target node can send a notification of resource return to the starting node, and inform the starting node of the status of the returned resource. On the starting node, step 210, receive a resource return notification or resource transfer notification. When the transfer share after the change is less than the transfer share before the change, or when the start node is deleted as the previous start node, the start node in the state of transferred resources will receive a resource return notification from the target node. The resource return notification includes the amount of the return, and may also include the cause of the resource return (such as changes to the transfer parameters). When the transfer share after the change is more than the transfer share before the change, the starting node in the state of transferred resources will receive a resource transfer notification from the target node. The resource transfer notification includes the share that the starting node needs to continue to transfer. The starting node in the state of untransferred resources will receive a resource transfer notification from the target node, including the share that the starting node needs to transfer. The resource transfer notification may also include the reason that caused the resource transfer to change. As mentioned above, the share to be transferred, the share to be transferred or the returned share of each starting node is determined by the target node according to the change of the transfer parameters and the transfer status of the starting node. On the starting node, step 220, according to the resource transfer notification to transfer resources to the target node. When the originating node receives the 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 transfer resources after confirmation by the user, or it can automatically transfer resources without limitation. It can be seen that in the first embodiment of the present invention, during or after the resource transfer is performed, the transfer parameters on the target node can be used by the target node to automatically follow the transfer status of each starting node The resource transfer between the start nodes is corrected to match the updated transfer parameters. When applied to the payment, it can avoid manual calculation and operation processes, improve the efficiency of error correction, and improve the user's convenience. Embodiment 2 of the present invention proposes a new method for realizing payment collection and payment. For the payment collection operation that has been submitted, the collection user can change the collection parameters, and according to the changed collection parameters and whether each payer pays In the current state, a payment notification is automatically issued to the payer or a refund is made to the payer, so that the changed payment result matches the changed payment parameters, which avoids the need for the receiving user to make the original payment parameters wrong. Calculate and manually correct the result of the current payment to reduce the user's operation and improve the efficiency of error correction, so as to solve the problems in the existing technology. In the second embodiment of the present invention, the terminal of the payment user and the payment server, and the terminal of the payment user and the payment server are mutually accessible through the network. Among them, the terminal of the payment user or the terminal of the payment user can be a mobile phone, tablet computer, PC, notebook computer, etc .; the payment server can be a physical or logical server, or it can be shared by two or more The entities or logical servers with different responsibilities cooperate with each other to implement the functions of the server in the second embodiment of the present invention. The beneficiary user and the payer user have their own accounts in the payment system operated by the payment server. The beneficiary user ’s terminal and the payer ’s terminal log in to the payment system using their respective accounts and make payments through their accounts Receiving and paying, the receiving user's account is the payee, and the paying user's account is the payer. In the second embodiment of the present invention, after the payment user starts the payment operation of a payment, the payment system provides the payment user with the function of modifying the payment parameters of the payment. The payer of the payment operation can be one, or two or more; the payment operation can be in progress (that is, the payment user has initiated the payment operation, but has not yet received payment from all the payers ), Or it may have been completed (that is, payment has been received from all payers); no limitation. In addition, the payment system can provide the function of modifying the payment parameters in the user terminal installed on the payment user terminal, and can also provide this function on the access page of the payment user terminal to the payment system, which is also not limited. In the second embodiment of the present invention, the flow of the method for implementing payment on the payee terminal or payment server is shown in FIG. 3, and the flow on the payer terminal is shown in FIG. 4. On the payee terminal or payment server, step 310, receive the changes to the payment parameters. In the second embodiment of the present invention, the payee has started the payment operation, and the received money is initiated by the payee to at least one payer. At the time of initiation, the collection operation has certain collection parameters. For the collection operation, the collection parameters usually include the total amount of money, the number of payers, each payer, and so on. After initiation, due to various reasons, the payment user needs to change one or more payment parameters. In the first implementation of the second embodiment of the present invention, the payment user changes the payment parameters that have started the payment operation through the user terminal installed on his terminal (ie, the payee terminal). In this implementation, both the client and the payment server can save all the payment parameters that have been started for the payment operation. According to the needs of the actual application scenario, either the client or the payment server can use the modified The payment parameter corrects the current execution result of this payment operation. In the implementation of correction by the user terminal, the method runs on the payee terminal, and the payee user gives instructions for changing the payment parameters on the user terminal of the terminal, and the payee terminal obtains from the change instruction The changed payment parameters. In the implementation of the correction by the payment server, the method runs on the payment server, the payment user gives instructions on the user terminal to change the payment parameters, and the payee terminal gets the modified payment from the change instruction Payment parameters, 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 (Global Information Network) mode to modify the payment parameters. In this implementation, this method runs on the payment server, and the payment user changes the payment parameters on his terminal. After the payment user confirms, 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 the payment server can also use other methods to obtain the payment user's changes to the payment parameters, which will not be described in detail. On the payee terminal or payment server, step 320, according to the changed 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, and pay at least one Party refund. After the payment user initiates the payment operation, the payment server will initiate a payment notification to the payer according to the current payment parameters, informing the payer of the share to be paid to the payee. When the payment user changes the payment parameters, the payment user may have paid the share before the change to the payee according to the previous payment notification, or it may not have paid yet. After the payment parameters are changed, the payer who has paid may need to make up the difference, refund the difference, or return all the paid share; for the payer who has not paid, you may need to change the share to be paid. Therefore, the payee terminal or payment server running the method should determine whether to receive or pay for each payer and the payment received according to the current payment status of each payer and the changed payment parameters Share. In the second embodiment of the present invention, the payment user can modify one or more payment parameters. The following example illustrates the processing method after modifying different payment parameters. In the first example, the receiving user specifies the total amount of money in the collection operation, and the payee terminal or payment server distributes the total amount of money to all payers according to a predetermined allocation algorithm. When the beneficiary user changes the total amount of payment, the beneficiary terminal or payment server applies the changed total amount of money to the predetermined allocation algorithm to obtain the changed share of each payer; for the payment status of each payment Payers, if the changed share is less than the pre-change share, the overpaid share will be refunded, if the changed share is greater than the pre-change share, the paid payer will be notified of the share to be paid back, if the changed share The same as the share before the change is not processed; for each payer whose payment status is unpaid, the unpaid payer is notified of the share to be paid according to the changed share. In the second example, when the payment user changes the payment parameters, one or more payers are added. The payer terminal or payment server determines the current payer and the changed share of each payer according to the changes to the payer. The current payer is the original payer (the payer before the change) and the new payer added In the aggregate, the increase of the payer will cause the share paid by one or more of the original payers to decrease (determined by how the total amount of money is allocated). Therefore, for each payer whose payment status is paid, the payer terminal or payment server returns the overpaid share when the changed share is less than the pre-change share; 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, it may be notified without notice. For newly added payers (the payment status is unpaid), follow The changed share is notified of the share to be paid. In the third example, when the receiving user changes the receiving parameters, one or more payers are deleted. The payer terminal or payment server determines the current payer, the deleted former payer, and the changed share of each payer (that is, the current payer) according to the changes to the payer. The current payer is not The deleted payer, the former payer is the deleted payer, the reduction of the payer will lead to an increase in the share paid by one or more payers. The payer terminal or payment server, for each payer whose payment status is paid, notifies the payer of the share to be repaid when the changed share is greater than the share before the change; for each payment state, it is an unpaid payment Party, when the changed share is greater than the share before the change, notify the unpaid payer of the share to be paid according to the changed share; for each former payer, if the payment status is paid, the entire paid share will be returned , Otherwise notify the former payer that there is no need to pay. In the fourth example, when the receiving user changes the receiving parameters, he changes one or more parameters of the total amount of payment, the number of payers, and the payer. The payer terminal or payment server determines the current payer (if the payer is not deleted) according to the changes to the payer (including the number of payers and changes to the payer), or determines the current payer and the deleted previous payment If the payer is deleted, the current payer includes the payer that has not been deleted and the new payer. The former payer is the deleted payer. The payer terminal or payment server determines the changed share of each payer based on the total amount of money after the change. For each payer whose payment status is paid, if the changed share is less than the pre-change share, the overpaid share will be returned, and if the changed share is greater than the pre-change share, the payer will be notified of the 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 is notified according to the changed share; for the former payer, If it has been 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, which will not be repeated here. Generally, the payee terminal determines the share that the payer needs to make up, the share that needs to be paid after the update, and / or does not need to pay according to the changed payment parameters and the payment status of the payer, and notifies at least through the payment server The share payable by a payer, and / or request the payment server to refund to at least one payer; specifically, the payee terminal submits the payer and the content that needs to be notified to the pay server, and the pay servo 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 manner in which the method runs on the payment server, the payment server may directly perform the steps of refunding the payment to the payer and notifying the payer. On the payer's terminal, in step 410, receive a refund notification or an updated payment notification, where the updated payment 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 returned share is determined according to the change of payment parameters of the received money 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 recipient to the payer (may be part of the paid share, or it may be the entire paid share), it will inform the payer of the refund amount and the refund party in the refund notice, The refund notice 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 terminal. If the payment status of the payer is paid and the share after the change is greater than the share before the change, the payment server will send a payment notification with the pay-out 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 share repayment. On the payer's terminal, step 420, according to the user's instruction, according to the received payment notice to pay to the payee. The payer terminal will display the received refund notice or collection notice to the paying user. The payment user can perform the payment operation to the payee in response to the payment notification. When the payer terminal receives the payment instruction of the payment 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 payee according to the share in the payment notification. It can be seen that in the second embodiment of the present invention, the payment user is provided with the function of modifying the payment parameter for the payment operation that has been submitted, and the payment user can change the payment parameter according to the changed payment parameter and each payer Payment status, automatically initiate payment notification to the payer or refund to the payer, so that the payment user does not have to calculate and manually correct the result of the current payment when the payment parameter input error occurs, improving the efficiency of error correction , Which improves the user's convenience. 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 collection function, and can automatically correct the current collection according to the user's changed payment parameters Payment result, complete AA collection. On the user terminal of the collection user terminal, for the AA collection order that has been initiated, the collection user can modify the total amount of payment, the number of payers, and / or the payer. The following is a specific example. Suppose the payee initiates an AA collection order with a total amount of 142 yuan and the number of payers is 7. After initiating the order, the user of the 7-digit payer terminal receives 20. 29 yuan collection notice. The receiving user finds that the statistics on the number of people are incorrect, and starts the function of modifying the payment parameters of the order on his user terminal. A user interface is shown in FIG. 5. Set the receiving user to reduce the number of recipients to 6, and delete one payee. The user interface after changing the payment parameters is shown in Figure 6. The payee terminal determines the current payee (6 digits not deleted) and the former payee (1 digit deleted) according to the new payment parameters, and determines the share of each current payee to 23 . 66 yuan. For the payer whose payment status is paid in this AA order, the payee terminal sends a payment notice to the payer terminal through the payment server of the third-party payment platform to inform the payer that the user needs to make up 3. 37 yuan difference. After receiving the payment notification, the payer terminal displays it to the paying user. A user interface is shown in FIG. 7. On this interface, the paying user can click to make up the difference 3. 37 ”to pay the payee through the payment server 3. 37 yuan. For the payer whose payment status is unpaid in this AA order, the payee terminal sends a payment notice to the payer terminal through the payment server, informing the paying user that the share to be paid is 23. 66 yuan. After receiving the payment notification, the payer terminal displays it to the paying user. A user interface is shown in FIG. 8. On this interface, the paying user can click "Pay 23." 66 "to pay the payee through the payment server 23. 66 yuan. For the deleted prepayer, if the payer has already paid, the payee terminal requests the payment server to return the entire share of the payment to the prepayer, and sends a refund notification to the prepayer terminal through the payment server . The terminal of the former payer shows the reason of the refund notification and the amount of the refund to the user of the previous payment. If the payer has not paid, the payee terminal sends a notification to the pre-payer terminal through the payment server to inform the pre-payer that there is no need to pay the AA order. Set the receiving user to increase the number of recipients to 8 and add 1 payee. The user interface after changing the payment parameters is shown in Figure 9. The payee terminal determines the current payer as the original 7 digits plus the newly added 1 digit according to the new payment parameters, and determines the share of each payer as 17. 75 yuan. For each payer whose payment status is paid in this AA order, the payee terminal requests the payment server to return to the payer 2. 54 yuan, and send a refund notice to the payer terminal through the payment server of the third-party payment platform to inform the payment user that the refund has been returned 2. 54 yuan difference. After receiving the refund notice, the payer terminal displays it to the paying user. A user interface is shown in FIG. 10. For each payer whose payment status is unpaid in this AA order (including the newly added payer), the payee terminal sends a payment notice to the payer terminal through the payment server, informing the payer that the share to be paid is 17 . 75 yuan. Corresponding to the implementation of the above process, embodiments of the present invention also provide an apparatus for implementing resource transfer applied to a target node, an apparatus for implementing resource transfer applied to a starting node, and an application to a payee terminal or payment A server payment realization device and a payment application realization device applied to a payer terminal. The above four devices can be implemented by software, or by hardware or a combination of hardware and software. Taking software implementation as an example, as a logical device, it is formed by reading the corresponding computer program instruction into the memory through the CPU (Central Process Unit, central processing unit) of the device. At the hardware level, in addition to the CPU, memory, and non-volatile memory shown in FIG. 11, the device where the above-mentioned device is located usually includes other hardware such as chips for wireless signal transmission and reception, and / or Boards and other hardware used for network communication. FIG. 12 shows an apparatus for implementing resource transfer provided by an embodiment of the present invention, which is applied to a target node for resource transfer. The apparatus includes a transfer parameter receiving unit and a resource transfer modifying unit, where the transfer parameter receiving unit is used to receive Changes to the transfer parameters; the resource transfer change unit is used to perform at least one of the following actions according to the changed transfer parameters and the transfer status of the starting node: notifying at least one starting node of the resource share to be transferred, starting from at least one The starting node returns part or all of the transferred resources. Optionally, the change of the transfer parameter includes one or more of the following: adding a start node, deleting the start node, and changing the total amount of resource transfer; the resource transfer modification unit is specifically used to: Change to determine the current starting node, or the current starting node and the deleted previous starting node, determine the changed transfer share of each starting node 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, the multi-transfer share is returned, and when the changed transfer share is greater than the transfer share before the change, the starting node of the transferred resource is notified that the transfer needs to continue the transfer Share; for the start node of each 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 newly added start node, follow the changed transfer The share notifies the starting node of the untransferred resource that the share needs to be transferred; the device further includes: a former starting node changing unit for the former starting node to return the transferred share if the resource has been transferred, otherwise notify The former start node does not need to perform resource transfer. FIG. 13 shows an apparatus for implementing resource transfer provided by an embodiment of the present invention, which is applied to a starting node of resource transfer. The apparatus includes a return or transfer notification receiving unit and a resource transfer execution unit, where: return or transfer The notification receiving unit is used to receive a resource return notification or a resource transfer notification, where the resource transfer notification includes an updated share to be transferred or a share that needs to be transferred, and the resource return notification includes part or all of the transferred resource share returned ; The share to be transferred, the share to be transferred or the returned share is determined according to the change of the transfer parameters of the transferred resource and the transfer status of the starting node; The resource transfer execution unit is used to notify the resource according to the resource transfer notification The transfer target node transfers resources. 14 shows a device for implementing payment collection provided by an embodiment of the present invention, which includes a payment parameter receiving unit and a payment collection modification unit, wherein: the payment collection parameter receiving unit is used to receive changes to payment collection parameters; and the payment collection modification The unit is used for performing 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 modification of the payment collection parameter includes: changing the total payment amount, and the total payment amount is distributed to each payer according to a predetermined allocation algorithm; the collection and payment change unit is specifically used to adopt the changed total payment amount 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 pre-change share, the overpaid share is returned, and when the changed share is greater than the change The former share is notified when the paid payer needs to make up the share; for each unpaid payer, the unpaid payer is notified of the required share according to the changed share. Optionally, the modification of the collection parameter includes: adding a payer; the collection and payment modification unit is specifically used to determine the current payer and the changed share of each payer according to the change to the payer; Each paid payer, when the changed share is less than the pre-change share, refund the overpaid share; for at least one unpaid payer, notify the unpaid payer according to the changed share of what needs to be paid Share. Optionally, the modification of the collection parameters includes: deleting the payer; the collection and payment modification unit is specifically used to determine the current payer, the deleted former payer, and each according to the changes to the payer The changed share of the payer; for each paid payer, when the changed share is greater than the share before the change, the paid payer is notified of the share to be paid; for each unpaid payer, When the changed share is greater than the share before the change, the unpaid payer is notified of the share to be paid according to the changed share; the device further includes: a pre-payer changing unit, which is used When paying, the refunded share will be returned, otherwise the former payer will be notified that there is no need to pay. Optionally, the change of the payment collection parameter includes one or more of the following: adding a payer, deleting the payer, and changing the total amount of payment; the payment collection and change unit is specifically used to determine the current The payer, or the current payer and the deleted former payer, determine the changed share of each payer according to the total amount of the change; for each paid payer, when the changed share is less than the change before The overpaid share will be refunded when the share is exceeded. When the changed share is greater than the share before the change, the said payer shall be notified of the share to be paid; for each unpaid payer, when the changed share is before the change If the share is different, or if the unpaid payer is a new payer, notify the unpaid payer of the share to be paid according to the changed share; the device further includes: a former payer changing unit, used For the former payer, if it has been paid, the paid share will be refunded, otherwise the former payer is notified that there is no need to pay. Optionally, the device is applied to the beneficiary terminal; the payment parameter receiving unit is specifically used to receive a user's instruction to change the payment parameter; the payment payment modification unit is specifically used to: The payment parameters and the payment status of the payer perform at least one of the following actions: notify the at least one payer of the share to be paid through the payment server, and request the payment server to refund the 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 modification request from the terminal of the payee. FIG. 15 shows an apparatus for implementing payment collection and payment provided by an embodiment of the present invention, which is applied to a payer terminal, and the device includes a collection and refund notification receiving unit and a collection and payment unit, where: When receiving a refund notice or collection notice, the collection notice includes the updated share to be paid or the share to be paid back, and the refund notice includes the returned part or all of the paid share; the payment required share 3. The share to be repaid or the returned share is determined according to the change of payment parameters of the received payment and the payment status of the payer; the payment payment unit is used to receive payment according to the instructions of the user according to the payment notification Payment. 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 should be included in the present invention Within the scope of protection. In a typical configuration, the computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory. Memory may include non-permanent memory, random access memory (RAM) and / or non-volatile memory in computer-readable media, such as read-only memory (ROM) or flash memory (flash) RAM). Memory is an example of computer-readable media. Computer-readable media including permanent and non-permanent, removable and non-removable media can be used to store information by any method or technology. The information can be computer readable instructions, data structures, modules of programs, 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 and programmable read-only memory (EEPROM), flash memory or other memory technologies, read-only disc read-only memory (CD-ROM), digital multifunction Optical discs (DVD) or other optical storage, magnetic cassette tapes, magnetic tape 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. As defined in this article, computer-readable media does not include temporary computer-readable media (transitory media), such as modulated data signals and carrier waves. It should also be noted that the terms "include", "include" or any other variant thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device that includes a series of elements includes not only those elements, but also includes Other elements not explicitly listed, or include elements inherent to this process, method, commodity, or equipment. Without more restrictions, the element defined by the sentence "include one ..." does not exclude that there are other identical elements in the process, method, commodity, or equipment that includes the element. Those 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 may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present invention may take 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 code .