Process a Pix Transfer
Process a previously initiated Pix cash-out and move funds between accounts. A cash-out whose Midaz debit outcome is unknown is still answered 201, at status CREATED, and keeps its initiation; its outcome arrives later by the transfer webhook. The request body is intentionally an opaque raw-bytes payload (no typed schema): unknown fields are ignored. The optional body field contestedMedRootTransactionId is the rootTransactionId of the funds recovery contested in the MED. It is required when X-Purpose is INSTANT_PAYMENT_REFUND and the destination is another PSP: after trimming, it must be exactly 32 ASCII letters, digits or underscores, and the trimmed value is sent to BTG. Such a refund is rejected before any Midaz debit with 400 PIX-0481 when the field is missing and 400 PIX-0482 when it is malformed. BTG receives it as a MANUAL payment to the destination account resolved at initiation, without the Pix key. An intra-PSP refund, which never reaches BTG, and the TRANSFER, WITHDRAWAL and CHANGE purposes ignore the field.
Encabezados
Transaction purpose (TRANSFER, INSTANT_PAYMENT_REFUND, WITHDRAWAL for a Pix Saque charge, CHANGE for a Pix Troco charge). Defaults to TRANSFER. An INSTANT_PAYMENT_REFUND to another PSP requires the body field contestedMedRootTransactionId (400 PIX-0481 when missing, 400 PIX-0482 when malformed). An intra-PSP refund and every other purpose ignore the field.
Cuerpo
The body is of type file.
Respuesta
Created
Transaction ID (txId) declared by the QR Code this cash-in paid. For a dynamic QR Code it is the charge's own txId, proven against that charge before the cash-in was accepted. For a static BR Code it is whatever reference label the code declared, which may match no charge. initiationType answers QR_CODE for both, so treat this as a correlation hint rather than proof a charge was paid. Absent for a payment with no QR Code and for every cash-out.
"cob7f3a9c2e4b118d"

