Payment notice and communication

The two exchanges a payer starts. Payment tells the provider money has moved; communication tells the provider something has changed or is wanted.

Payment notices​

What accounts do​

A payment run screen, built from approved claims: select the claims, initiate the transfer, and record the bank's confirmation and UTR as it comes back. Each stage becomes a notice. Deductions, TDS and any scheme adjustments are entered per claim, and the net is what the bank receives.

What the system calls​

POST /v1/paymentnotice/request      workflows 30, 31, 33
receive /v1/paymentnotice/on_request   the provider's acknowledgement, workflow 17

Three notices per claim as the money moves: 30 initiated, 31 processed by the bank, 33 settled with the UTR. Each is a separate message with its own correlation ID. Send 33 only when the bank has confirmed; under PMJAY it is the gate that lets the provider raise a shortfall claim.

What goes in the bundle​

A collection bundle: a Task with code deliver and an input referencing the notice, a PaymentNotice, a PaymentReconciliation, and the two Organizations.

Task​

status = requested, intent = order, code = deliver. requester is the payer, owner the provider, and input[0].valueReference points at the PaymentNotice.

PaymentNotice​

The claim number as an identifier of type CLN, recipient the provider, amount the net, paymentStatus paid or cleared, and payment referencing the reconciliation.

PaymentReconciliation​

The same claim number, paymentDate, paymentAmount as the net, a paymentIdentifier of type UTR carrying the bank reference, and detail[] with one line per money type: TDS, Payment, and any of approvedamount, claimedamount, servicetax, advance, recovered, penality.

The provider will check that net plus deductions equals the approved amount. Make it so.

The acknowledgement​

Arrives as a Task with status = completed, code status, and an output whose value is paymentack, with the claim number as a second output. It confirms receipt, not agreement. Record it against the claim and consider the payment lifecycle closed once the acknowledgement of 33 is in.

A return payment, where money has to come back, has its own codes: RP1 intimation, RP2 acknowledged, RP3 failed.

Communication requests​

What the user does​

A composer, usually opened from a case: choose the reason, write the message, set a priority, send. Some are generated by the system rather than a person. A TAT alert when a provider has not answered a query within the window, a wallet update when a beneficiary's balance changes, a policy change when the plan master is versioned.

What the system calls​

POST /v1/communication/request
receive /v1/communication/on_request   the provider's acknowledgement

Reasons, on Task.reasonCode: tatquery, grievance, walletupdate, policychange, additionalinfo, claimArbitration. The last is sent automatically when an appeal Task is received, so the provider knows it is in the Committee's queue.

On the general network, additionalinfo is how a payer asks for documents outside a formal query. Under PMJAY, document queries go through the queried ClaimResponse instead, and this channel is for the other five.

What goes in the bundle​

A collection bundle of three parts.

Task​

Code poll, intent = proposal, reasonCode set, and an input of type include referencing the Communication.

Communication​

The case number as identifier, status = completed, a category (reminder, notification, instruction, questionnaire), a priority (routine, urgent, asap, stat), a topic (progress-update for anything about a live case), and the payload.

The two Organizations​

Payer first, then the provider.

The acknowledgement comes back as the same shape with the provider Organization first and the same correlation ID. It means received, not resolved; track resolution in the case, not in the exchange.

What a provider does with each notice​

Sending all three matters more than it looks, because the provider's case state and its shortfall window both hang off them.

Send 33 only when the bank has actually confirmed. Under PMJAY the acknowledgement of 33 is the gate that opens the provider's shortfall window, so sending it early opens that window against a payment that has not landed.

Notifying the beneficiary​

Where a beneficiary's app has subscribed, the exchange itself pushes a human-readable message on each event: "Preauthorisation approved for Rs. 50,000, valid until…". The payer does nothing extra; its normal responses feed it. The payer's own notifications carry workflow N01.