Paga i tuoi venditori con puntualità.

Perché un marketplace CS-Cart ha bisogno di una routine di pagamento

Multi-Vendor sa già quanto deve a ogni venditore. La pagina Accounting somma gli ordini, sottrae commissioni e rimborsi e tiene un saldo per venditore. Non decide quando pagare quel saldo, non trattiene il denaro finché i rimborsi sono possibili, non conserva i dati bancari e non produce alcun file leggibile dalla tua banca.

Con pochi venditori basta un export mensile. Con 30 o 50, il giorno di pagamento diventa una sessione di controlli dei saldi, IBAN copiati e bonifici uno per uno, e arrivano gli errori classici: pagare un venditore per un ordine rimborsato la settimana dopo, pagare due volte o pagare un conto modificato il giorno prima da chi non doveva.

Vendor Payouts Automation aggiunge questa routine attorno alla contabilità del core. Non tiene un secondo libro mastro: ogni richiesta di pagamento è un prelievo del core, quindi il saldo di Accounting resta l’unica cifra che conta.

Un ciclo di pagamento, passo dopo passo

1. Arriva un ordine. La contabilità del core lo aggiunge al saldo del venditore, al netto della commissione, e l’add-on annota il momento in cui raggiunge uno stato di inizio trattenuta (Complete per impostazione predefinita).
2. Passa il periodo di trattenuta (14 giorni per impostazione predefinita). Solo allora il denaro di quell’ordine diventa pagabile.
3. Il giorno di pagamento, il processo crea una richiesta per ogni venditore che ha i dati di pagamento, non ha richieste in sospeso e supera l’importo minimo. L’importo lascia subito il saldo, come prelievo in sospeso del core.
4. Approvi le richieste nella coda. Formano un lotto, e l’add-on salva una copia dei dati di ogni venditore in quel momento, così una modifica successiva non può deviare un pagamento in corso.
5. Scarichi il file del lotto, paghi tramite la banca o PayPal e segni il lotto come pagato con il tuo riferimento. I prelievi passano a Completed nella contabilità del core e i venditori ricevono un’e-mail «payout sent».

I venditori seguono tutto questo in una pagina Payouts accanto ad Accounting: saldo, denaro trattenuto, importo disponibile, prossima data di pagamento, storico ed estratti mensili. Di solito questa pagina mette fine ai ticket «quando verrò pagato?». Se un venditore è stato saltato, la pagina Vendor balances dà il motivo nell’ultima colonna, per esempio Below the minimum payout, No payout details o A request is waiting for approval.

Le impostazioni da decidere prima dell’attivazione

Le richieste automatiche sono disattivate dopo l’installazione, di proposito. Controlla la pagina Vendor balances, chiedi ai venditori di inserire i loro dati, configura il cron e solo dopo attivale. Il processo richiede una chiamata cron giornaliera; senza cron parte anche al massimo ogni 15 minuti quando amministratori o venditori lavorano nel pannello, mai sul negozio.

Il calendario di un venditore prevale su quello del piano, e il piano prevale sulle impostazioni dell’add-on. Così si concedono pagamenti settimanali a un grande venditore senza cambiare nulla per gli altri.

Quale file di pagamento ti serve?

• CSV per tutti i metodi: fogli di calcolo, bonifici manuali e contabilità.
• File PayPal Payouts: una riga per richiesta PayPal, da caricare in PayPal Business.
• SEPA XML (pain.001.001.03): un pagamento per richiesta bancaria con IBAN, da caricare nella banca online. Proposto solo se la valuta principale del negozio è EUR. Le richieste con numero di conto senza IBAN vanno nel CSV.

Cosa non fa

Non invia denaro. Non c’è connessione diretta a Stripe Connect, all’API PayPal Payouts o a Wise; paghi con il file e poi segni il lotto come pagato. È una scelta: sei tu a sbloccare i fondi.

Tutti gli importi sono nella valuta principale del negozio, e i rimborsi dopo il pagamento sono gestiti dalla contabilità del core: il pagamento successivo è più basso, e un saldo negativo blocca i pagamenti finché non torna positivo. Sul negozio non cambia nulla.

Con Direct Customer-to-Vendor Payments o Stripe Connect l’add-on funziona ancora, ma vede solo ciò che resta nel saldo dopo la ripartizione al pagamento, per esempio una commissione negativa.

L’add-on richiede Multi-Vendor. Su CS-Cart Standard o Ultimate l’installazione viene rifiutata, perché lì i saldi venditore non esistono.

Add-on di pagamento, ripartizione alla cassa o foglio di calcolo?

Se il tuo gateway gestisce la ripartizione marketplace e i venditori accettano di essere pagati per ordine, la ripartizione può essere più semplice. I pagamenti pianificati convengono ai marketplace che vogliono trattenere il denaro durante il termine di reso o che pagano con bonifico. Le due cose possono convivere.

Una combinazione tipica: Advanced Commission Rules fissa la commissione, questo add-on paga il resto e Vendor KYC & Verification può bloccare i pagamenti fino alla verifica del venditore. L’elenco completo è nella pagina degli add-on Multi-Vendor; puoi acquistare Vendor Payouts Automation sul negozio.

Versioni e requisiti

Multi-Vendor da 4.17.2 a 4.21.x su PHP da 7.2.5 a 8.3, secondo ciò che supporta la tua versione di CS-Cart. Il file SEPA richiede l’estensione PHP XMLWriter, attiva quasi ovunque. Nessun file o tabella del core viene modificato: l’installazione aggiunge tabelle proprie, due privilegi e quattro modelli di e-mail. La disinstallazione li rimuove, e i prelievi creati restano nella contabilità del core, quindi i saldi non si muovono.