Skip to main content
Send, receive and return TED when a partner connects your institution to STR.
This page suggests one way to read the BACEN manuals for TED. The partner’s documentation and the manuals prevail over this page. Your institution, as the participant, validates the flow and implements it on the Lerian APIs. See how to read the diagrams.

TED through JD


Participants

  • Your institution. Calls the TED JD API and reads the result of each TED.
  • TED JD. The connectivity interface between Midaz and JD. It posts each TED in Midaz and exchanges the TED messages with JD.
  • Midaz. The ledger that holds the accounts of your customers.
  • STR. The BACEN reserve transfer system. It settles each TED.
  • JD. The partner that exchanges the TED messages with STR.
  • Other institution. The institution at the other end of a TED that your institution receives or that comes back.

Before you start

  • TED JD is set up for your institution. See Configuration.
  • The account that sends, receives or returns the TED exists in Midaz and has a holder.
  • Where webhook delivery is on for your deployment, register your endpoint with POST /v1/webhooks. GET /v1/webhooks/event-types lists the events you can subscribe to.
  • To return a received TED, each operation route of the TED credit in Midaz has the operationType bidirectional. See Accounting Routes.

Send a TED through JD

TED through a partner: Send a TED through JD

Receive a TED through JD

TED through a partner: Receive a TED through JD

A sent TED comes back through JD

TED through a partner: A sent TED comes back through JD

Return a received TED through JD

TED through a partner: Return a received TED through JD

Rules for JD

Send a TED

  • TED JD sends one TED per initiation. When you confirm the same initiationId again, TED JD does not send a second TED.
  • The reservation in Midaz is not the settlement.

Receive a TED

  • When JD delivers the same TED again, TED JD does not credit it again.

A sent TED comes back

  • The credit is a new received transfer with its own transferId. Its originalTransferId names the TED you sent.
  • Where your institution’s configuration turns it on, a return of the whole amount can also give back the fee of the TED you sent.
  • A return that reaches a TED you sent before it completed is not refunded on its own. The webhook transfer_outgoing.devolution_notified carries a transferStatus other than COMPLETED. If the TED completes, an operator refunds the payer with the REFUND action of POST /v1/transfers/{transferId}/reconciliation/resolve.

Return a received TED

  • The return sends back the full amount of the received TED.
  • The return is a new transfer of type TED_OUT with its own transferId. The received TED stays COMPLETED.

How you know it finished with JD

  • Send a TED. The webhook transfer.completed or transfer.rejected reports the final status. After a reconciliation, the webhook transfer.reconciliation_resolved or transfer.reconciliation_failed reports it, and the TED can also end FAILED. GET /v1/transfers/{transferId} shows the status.
  • Receive a TED. The webhook transfer_incoming.completed reports the credit. GET /v1/transfers/{transferId} shows the received TED in COMPLETED.
  • A sent TED comes back. The webhook transfer_outgoing.devolution_notified reports the return, and transfer_incoming.completed reports the credit. GET /v1/transfers/{transferId} shows the TED you sent with a devolutionCode.
  • Return a received TED. The webhook transfer_incoming.returned or transfer_incoming.return_rejected reports the final status. GET /v1/transfers/{transferId} with the transferId of the return shows COMPLETED or REJECTED.

What can go wrong with JD

Send a TED

Receive a TED

Return a received TED