mich3lang3lo

Olá pessoal! Tudo bem?

Estou respondendo a mensagem anterior com uma atualização: conseguimos identificar exatamente a causa do erro e uma correção mínima que resolve o cenário “Recorrência + Split Dokan”.

Causa raiz confirmada

No fluxo de cartão de crédito, o plugin monta o payload de criação do pedido (ws/orders) com:

• charges[0].recurring (INITIAL/SUBSEQUENT) quando é compra recorrente
• charges[0].splits.receivers[].configurations.liable sempre presente no split do Dokan, inclusive quando o valor é false (o campo existe no payload)

Quando esses dois itens aparecem juntos, a API retorna:

40002 – invalid_parameter (charges[0].recurring)
RECURRING PAYMENT IS NOT VALID FOR SPLIT TRANSACTIONS WITH LIABLE CONFIGURATION

Ou seja: para recorrência, a API não aceita “liable configuration” no split (mesmo liable=false, apenas existir o campo já dispara o erro). Onde isso ocorre no plugin (para facilitar revisão)

• Entrada WooCommerce (cartão): pagbank-connect/src/Connect/Standalone/CreditCard.php (process_payment)
• Payload / charges / recurring: pagbank-connect/src/Connect/Payments/CreditCard.php (prepare)
• Split Dokan + liable:
  • pagbank-connect/src/Integrations/Dokan/DokanSplitManager.php (setLiable no receiver do marketplace e vendor)
  • pagbank-connect/src/Object/Receiver.php (setter grava em configurations['liable'])
• Envio HTTP: pagbank-connect/src/Traits/ProcessPayment.php (makeRequest -> ws/orders)
• Log do payload: pagbank-connect/src/Helpers/Api.php (log de params)

Solução mínima (patch sugerido)

Quando a cobrança é recorrente (INITIAL ou SUBSEQUENT), o plugin deve remover completamente configurations.liable de todos os receivers do split antes de enviar o request.
Importante: não setar liable=false, mas sim não enviar o campo (unset), pois o erro ocorre quando a “liable configuration” existe no payload.

Abaixo segue um patch simples aplicado no builder de cartão (ponto central), antes do envio:

--- a/pagbank-connect/src/Connect/Payments/CreditCard.php
+++ b/pagbank-connect/src/Connect/Payments/CreditCard.php
@@
         elseif (\RM_PagBank\Integrations\GeneralSplitManager::shouldApplySplit($this->order)) {
             $splitData = \RM_PagBank\Integrations\GeneralSplitManager::buildSplitData($this->order, 'CREDIT_CARD');
             $charge->setSplits($splitData->jsonSerialize());
         }
         //endregion
+
+        // PagBank does not allow liable configuration on recurring charges.
+        if ($this->isRecurringCharge()) {
+            $splitPayload = $charge->getSplits();
+            if (!empty($splitPayload['receivers']) && is_array($splitPayload['receivers'])) {
+                foreach ($splitPayload['receivers'] as &$receiver) {
+                    if (isset($receiver['configurations']['liable'])) {
+                        unset($receiver['configurations']['liable']);
+                    }
+                    if (isset($receiver['configurations']) && empty($receiver['configurations'])) {
+                        unset($receiver['configurations']);
+                    }
+                }
+                unset($receiver);
+                $charge->setSplits($splitPayload);
+            }
+        }
@@
         $return['charges'] = [$charge];
         return $return;
     }
+
+    protected function isRecurringCharge(): bool
+    {
+        return (bool) $this->order->get_meta('_pagbank_recurring_initial')
+            || wc_string_to_bool((string) $this->order->get_meta('_pagbank_is_recurring'));
+    }

Comportamento após o patch

• Recorrência + Split Dokan: o request mantém recurring, mantém splits, mas sem configurations.liable → deixa de retornar 40002.
• Pagamento único: continua enviando liable normalmente (nenhuma alteração).
• Não removemos outros campos de split (chargeback/custody etc.).

Pedido

Vocês poderiam validar se esse é o comportamento esperado e, se sim, incorporar algo equivalente no plugin (ou expor um filtro/hook para ajustar o payload antes do POST)?

Se preferirem, eu posso também enviar um log sanitizado do payload “antes/depois” para comprovar a diferença no request.

Obrigado!
Matheus R

Hi @teodor-cosofret,

In my case i am not using the recover password form, if the user needs to change the password he need to log in and change it in the page builder profile page, if he doesn´t know the password he can email me and i reset it, almost all my users don´t have an email, that´s why is very important to me to track any change in the account.

Thanks for the help

Mike

Shaon,

About the Advanced TinyMCE, is it working with the google drive addon?

Thank you

Mike

Im trying to find a work around but nothing is working.

Thanks for the help

Mike

Thank you for your help, i will keep an eye in the other thread.

Mike