Skip to main content
MovingPay is the back office platform used by sub-acquirers, payment facilitators, and marketplaces to run their payment operation. The connector extracts your transactions and their installments, the payment schedule of your merchants, anticipations, chargebacks, cancellations, and adjustments, along with the registry around them: merchants, sellers, bank accounts, devices, split rules, fee plans, acquirer agreements, card brands, acquirers, and MCC categories. With it you can analyze your sales volume, costs and margins, receivables, and settlements in your Lakehouse.
The connector reads the MovingPay API documented at documentacao.movingpay.com.br. MovingPay has no test environment, so the connector always reads your production data (read-only).

Configuring MovingPay as a Source

In the Sources tab, click on the “Add source” button located on the top right of your screen. Then, select the MovingPay option from the list of connectors. Click Next and you’ll be prompted to add your access.

1. Add account access

The connector signs in with the e-mail and password of a MovingPay user of your company, the same credentials used to access the MovingPay console. If MovingPay issued an access token for your integration, you can use it instead.
Create a MovingPay user dedicated to this integration. Its profile must be able to see the data of every stream you select. If it cannot see a stream, the run log names the stream: give the user access to it in MovingPay or deselect that stream.
The following configurations are available:
  • Authentication Method: choose E-mail and password (recommended) or Access token issued by MovingPay. Required.
  • E-mail and Password: the credentials of the MovingPay user. Shown when the method is e-mail and password.
  • Access Token: the token issued by MovingPay. Shown when the method is access token.
  • Customer ID: the MovingPay code of your company. MovingPay asks for it on every request (in a Customer header) to know whose data to return. With e-mail and password the connector takes it from the sign-in, so fill it in only when the user has access to more than one company. With an access token it is required.
  • Start Date: on the first sync, transactions, anticipations, and acquirer adjustments from this date on are extracted. Later syncs continue from where the previous one stopped. Required.
  • Lookback Days (advanced): how many days before the last synced date are read again on every sync, so recent records whose status changed (for example, a sale cancelled a few days later) are updated. The default is 30.
  • Installments Lookback Days (advanced): the installments of a sale are read for the sales of this many days before today, when the Transaction Installments stream is selected. The connector makes one request per sale, so a large value makes syncs much slower. The default is 2.
  • Payment Schedule Past Days and Payment Schedule Future Days (advanced): the range of the payment schedule, in days before and after today. The defaults are 30 and 365.
  • Requests Per Minute (advanced): how fast the connector may call MovingPay. The default is 300.
MovingPay may only accept API sign-ins from IP addresses it has allowed. If so, the first sync fails with a message saying the sign-in was refused because of the IP address. Ask MovingPay support to allow Nekt’s IP addresses for your company’s API access (contact Nekt support for the list), then run the sync again. Doing this before the first sync avoids the failed run.
Once you’re done, click Next.

2. Select streams

Choose which data streams you want to sync. For faster extractions, select only the streams that are relevant to your analysis. You can select entire groups of streams or pick specific ones.
Tip: The stream can be found more easily by typing its name.
Select the streams and click Next.

3. Configure data streams

Customize how you want your data to appear in your catalog. Select the desired layer where the data will be placed, a folder to organize it inside the layer, a name for each table (which will effectively contain the fetched data) and the type of sync.
  • Layer: choose between the existing layers on your catalog. This is where you will find your new extracted tables as the extraction runs successfully.
  • Folder: a folder can be created inside the selected layer to group all tables being created from this new data source.
  • Table name: we suggest a name, but feel free to customize it. You have the option to add a prefix to all tables at once and make this process faster!
  • Sync Type: Transactions, Transaction Installments, Anticipations, Chargebacks, Cancellations, and Acquirer Adjustments support INCREMENTAL. The other streams are FULL_TABLE. Read more about Sync Types here.
Once you are done configuring, click Next.

4. Configure data source

Describe your data source for easy identification within your organization, not exceeding 140 characters. To define your Trigger, consider how often you want data to be extracted from this source. This decision usually depends on how frequently you need the new table data updated (every day, once a week, or only at specific times). Optionally, you can define some additional settings:
  • Configure Delta Log Retention and determine for how long we should store old states of this table as it gets updated. Read more about this resource here.
  • Determine when to execute an Additional Full Sync. This will complement the incremental data extractions, ensuring that your data is completely synchronized with your source every once in a while.
Transaction Installments can’t be fully synced: the connector only reads the installments of recent sales, so a full sync would replace the table with a few days of installments. If that stream is selected, a full sync stops with a message before anything is synced. So don’t schedule an Additional Full Sync while Transaction Installments is selected: every one of those runs would fail. When you need a full sync, either deselect Transaction Installments for that run (its table keeps its data) and select it again afterwards, or run the full sync only for the other streams.
Once you are ready, click Next to finalize the setup.

5. Check your new source

You can view your new source on the Sources page. If needed, manually trigger the source extraction by clicking on the arrow button. Once executed, your data will appear in your Catalog.
For you to be able to see it on your Catalog, you need at least one successful source run.

Streams and Fields

Below you’ll find all available data streams from MovingPay and their corresponding fields. API reference: MovingPay API.
Timestamps are stored in UTC, the time zone MovingPay records them in. Amounts are in cents, as MovingPay returns them. Objects and lists (such as split rules) are stored as JSON text, and every table also has a raw_payload column with the whole record as MovingPay returned it.
A transaction’s status can change after the sale (cancellation, chargeback). Each sync re-reads the last Lookback Days of sales to capture these changes; a sale older than that keeps the status it had when it was last read. For later events, use the Chargebacks and Cancellations streams, which are read in full on every sync, and the Payment Schedule for the payment status of receivables.
Merchants (establishments) accredited by your company, with their fee plan, seller, anticipation settings, and status (GET /estabelecimentos).Table: merchants · Primary key: codigo_cliente · Sync: Full table
Card and payment transactions (GET /transacoes), with amounts, costs, card, capture, and status. Read by sale date: each sync reads the sales since the previous one and re-reads the lookback days before it, so recent sales that were cancelled or disputed are updated.Table: transactions · Primary key: id · Sync: Incremental on start_date
Installments (receivables) of recent transactions, with gross and net amounts, fees, payment dates, and split data (GET /transacoes/parcelas). This stream makes one request per transaction, so it is not selected by default and only reads the sales of the last Installments Lookback Days; each installment is read shortly after its sale and not refreshed afterwards. For the same reason it only runs incrementally: a full sync with this stream selected stops before anything is synced, so don’t combine it with an Additional Full Sync (see step 4).Table: transaction_installments · Primary key: id · Sync: Incremental on transaction_start_date
Payments scheduled to the merchants (GET /financeiro/detalhado), both waiting for funds and already paid. The table is rebuilt on every sync with the entries from Payment Schedule Past Days before today to Payment Schedule Future Days after it.Table: payment_schedule · Primary key: row_key · Sync: Full table
Receivable anticipations, spot and automatic (GET /relatorios/antecipacoes). Read incrementally by their last update.Table: anticipations · Primary key: id · Sync: Incremental on updated_at
Chargebacks registered for your transactions (GET /relatorios/chargebacks). The whole list is read on every sync and merged into the table.Table: chargebacks · Primary key: id · Sync: Incremental on data_contestacao
Cancellations registered for your transactions (GET /relatorios/cancelamentos). The whole list is read on every sync and merged into the table.Table: cancellations · Primary key: id · Sync: Incremental on data_cancelamento
Adjustments posted by the acquirers, such as chargeback and cancellation debits (GET /adquirentes/lancamentos). Read incrementally by the adjustment date.Table: acquirer_adjustments · Primary key: id · Sync: Incremental on data_ajuste
Credit and debit adjustments still pending for the merchants (GET /lancamentos). The table holds the adjustments pending at the time of the sync.Table: pending_adjustments · Primary key: id · Sync: Full table
Sellers (distributors) that bring merchants to your company (GET /distribuidores).Table: sellers · Primary key: id · Sync: Full table
Bank accounts that receive the settlements of merchants and sellers (GET /conta-bancaria).Table: bank_accounts · Primary key: id · Sync: Full table
Capture devices (POS, mobile, TEF) and the merchants using them (GET /dispositivos).Table: devices · Primary key: id · Sync: Full table
Payment split rules registered for the merchants (GET /regras-de-divisao).Table: split_rules · Primary key: codigo_estabelecimento, hash · Sync: Full table
Fee plans assigned to the merchants (GET /estabelecimentos/planos).Table: fee_plans · Primary key: id · Sync: Full table
Commercial agreements with the acquirers: rates and costs per brand and product (GET /acordos).Table: acquirer_agreements · Primary key: id · Sync: Full table
Card brands and their rates per operation (GET /bandeiras).Table: card_brands · Primary key: id · Sync: Full table
Acquirers configured for your company (GET /parametros/adquirentes).Table: acquirers · Primary key: id · Sync: Full table
MCC and CNAE categories used to classify the merchants (GET /tabelas/cnae).Table: mcc_categories · Primary key: id · Sync: Full table