Authorise payment

Completes the JSR payment for a consent created by Create payment consent, after the payer performs the FIDO2 gesture (navigator.credentials.get()). Send enrollmentId, paymentRequestId (the id returned by Create payment consent), riskSignals, and fidoAssertion matching the WebAuthn credential — the ASPSP authorises and settles the Pix.

The envelope data follows RetornoPaymentRequestDto (request-level status, payments[], etc.) — the same shape you get back from Get payment request.

curl --request POST \
  --url 'https://embedded-payment-manager.hml.linaob.com.br/api/v1/jsr/payments' \
  --header 'Content-Type: application/json' \
  --header 'Authorization: Bearer <SEU_TOKEN>' \
  --header 'x-client-ip: 198.21.104.1' \
  --header 'subTenantId: subtenant_abc123' \
  --data '{
  "enrollmentId": "enr_abc123",
  "paymentRequestId": "pay_req_xyz",
  "riskSignals": {
    "deviceId": "00aa11bb22cc33dd",
    "osVersion": "14",
    "userTimeZoneOffset": "-03",
    "language": "pt",
    "screenDimensions": {
      "width": 1080,
      "height": 2340
    },
    "accountTenure": "2023-08-20"
  },
  "fidoAssertion": {
    "id": "PHTfZjunYYbZqbHcE7cRewO4QUCI5FLfl_NFLXHDWPs",
    "rawId": "PHTfZjunYYbZqbHcE7cRewO4QUCI5FLfl_NFLXHDWPs",
    "response": {
      "authenticatorData": "ZynbwP-T2rhdodTWL28bNVIvLR9PJWFgR8TC-gttcR4FAAAAAQ",
      "clientDataJSON": "eyJ0eXBlIjoid2ViYXV0aG4uZ2V0IiwiY2hhbGxlbmdlIjoiYlhGV2VrMWpZVk5qZEdadVVVRSIsIm9yaWdpbiI6Imh0dHBzOi8vcGFzc2tleS1hdXRoLXJlZ2lzdGVyLnZlcmNlbC5hcHAiLCJjcm9zc09yaWdpbiI6ZmFsc2V9",
      "userHandle": "15e200d8-c7ff-4a95-90a5-1c461e03a099"
    },
    "type": "public-key",
    "clientExtensionResults": {},
    "authenticatorAttachment": "platform"
  }
}'

{
  "data": {
    "id": "pay_req_xyz",
    "createDateTime": "2024-06-01T12:00:00Z",
    "lastChangedDateTime": "2024-06-02T12:00:00Z",
    "externalComment": "Payment processed",
    "externalId": "ext123",
    "cpfCnpj": "12345678901234",
    "redirectUri": "http://example.com/redirect",
    "tenantId": "tenant123",
    "consentId": "consent_xyz",
    "value": 1500.5,
    "status": "CONSUMIDO",
    "creditor": {
      "name": "Merchant SA",
      "personType": "PESSOA_JURIDICA",
      "cpfCnpj": "12345678000195",
      "accountNumber": "1234567890",
      "accountIssuer": "0001",
      "accountPixKey": "email@example.com",
      "accountIspb": "12345678",
      "accountType": "CACC"
    },
    "debitor": {
      "accountNumber": "1234567890",
      "accountIssuer": "0001",
      "accountIspb": "12345678",
      "accountType": "CACC"
    },
    "type": "SINGLE",
    "payments": [
      {
        "id": "pay_leg_1",
        "endToEndId": "E47133056202409201011eCPvUq3GjmK",
        "dueDate": "2024-06-01T12:00:00Z",
        "externalComment": "Payment processed",
        "txId": "ext123",
        "externalPaymentId": "consent_xyz",
        "status": "PAGO",
        "rejectionReason": null,
        "rejectionReasonDetail": null
      }
    ],
    "requestExpiresAt": "2024-09-01T12:00:00Z",
    "businessCnpj": "12345678000195",
    "localInstrument": "MANU"
  },
  "message": "",
  "type": "success",
  "statusCode": null
}

How payment status settles: synchronous check, webhook, and polling

In synchronous mode, POST /api/v1/jsr/payments performs up to 10 internal status checks against the account holder before it responds, trying to return a final status (PAGO / REJEITADO) directly in this response. In the large majority of cases this is enough — Pix has a tight settlement SLA, and the payment reaches a final status inside that window.

If the response comes back without a final status (still PENDENTE / EM_PROCESSAMENTO), don't treat that as a failure: call Get payment request with the same paymentRequestId to fetch the latest state. Two things happen in parallel to eventually update it, in case the window above wasn't enough:

• Webhook — Lina fires a webhook whenever the payment's status changes, as soon as the account holder reports it. See Webhooks — treat the notification as a signal only and always confirm with a GET.
• Internal polling — Lina also runs a background job that re-checks any payment without a final status every two hours, independent of the webhook.

You can additionally run your own client-side polling, querying the account holder directly (bypassing Lina's cached record) via Get payment from holder — useful if you don't want to depend solely on the webhook or Lina's internal polling cadence.

Next steps

• Get payment request — confirm the latest status by paymentRequestId.
• Get payment from holder — force a live check directly at the account holder.
• Compare payment leg status values with Instant Pix status tables for UX copy.