Philip Liu

Rather than calling the customer callback in NotifyCustomerInfoUpdated. What do you think of introducing a new parameter called status (SEP-12 status)? The business server should have access to the customer...

> So we need to make a call to BS either way Right. The new failure mode I was trying to avoid was more along the lines of calling a...

Also, the `ACCEPTED` status probably should not move the transaction into `pending_user_transfer_start` as this is handled by the request funds RPCs.

This is how it works at the moment: 1. Business server calls `NotifyCustomerInfoUpdated(status = status, tx = TX_ID)` 2. RPC service updates transaction TX_ID with new transaction status 3. Event...

There is always a risk that the customer's status may change before the event processor makes the callback. The issue arises from the latency between steps 2 and 4, during...

I understand your point. Does the client need to see the `PROCESSING` status? If the customer quickly moves between statuses, they might only care about the final status. There is...

@leighmcculloch We can close this for now. This will need to be updated post CAP-71 anyway so I'll just create a new PR then.

> Do we need the `destination_asset` in the response? > > ``` > { > "destination_asset": "stellar:USDC:G..." > } > ``` This was a typo. Fixed!