-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ANCHOR-746] Add SEP-12 customer callback support #1444
Comments
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 status and we can avoid new failure mode in the RPC this way. |
We could do that, but the idea is that in a callback we need to pass the the formed KYC response in the callback, back to the wallet. So we need to make a call to BS either way Ref:
|
Right. The new failure mode I was trying to avoid was more along the lines of calling a callback from an RPC. We don't do this today. The customer callback will be made in the callback event processor. |
Also, the |
I think we need to make the request from RPC while processing the |
This is how it works at the moment:
If I understand correctly, @JakeUrban, you are suggesting we make a customer request at 2? |
Yes thats right 👍 |
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 which these status changes can occur. It's unclear if making another request at step 2 would reduce this latency. I think this situation is acceptable anyway. A change in the customer's status should trigger another |
Lets say I'm an business and my customers go from If we go with the current approach, the business will make a Then the business could finish processing and make another Now there are two customer callback status change events, but when the event processor calls the business' |
I understand your point. Does the client need to see the If we want this behavior, your approach works. However, I'm not sure about sending events from the RPC handler. Maybe there are other options we can consider. We can explore the implementation in the PR rather than discussing it here. |
### Description Addresses #1444. This change: - Updates the `NotifyCustomerInfoUpdated` RPC so that it updates the transaction based on the requested Customer's status and sends a Customer updated event. `customerId` and `type` are new parameters needed to distinguish whether a customer is a SEP-31 receiver, sender, or a SEP-6 customer. - Updates SEP-12 service such that it passes the full SEP-12 customer into the `AnchorEvent`. Previously only the customer ID was present in the event. This is not a breaking change since the SEP-12 customer object is serializer backward compatible since it also contains an ID. - Sends a SEP-12 status callback to all clients. Callback configuration and end-to-end tests will be added in another PR. ### Context N/A ### Testing - `./gradlew test` ### Documentation stellar-docs PR will be created ### Known limitations N/A
Background:
Following SEP-6 flow update, the KYC gathering logic is now the following:
Once SEP-6 transaction is in the
pending_customer_info_update
, wallet should call SEP-12 GET/customer?transaction_id=<id>
to gather all KYC fields that is expected to be provided.Wallet then calls PUT
/customer?transaction_id=<id>
to update KYC. GET/PUT are called in sequence until KYC reaches ACCEPTED/REJECTED status. This works well until PROCESSING is added to the flow. In that case wallet needs to continuously pull GET /customer to check if status has been updated. This is not ideal considering that this call would need to be made from the user device for non-custodial wallets.Instead, we should add SEP-12 customer callback that notifies wallet backend about necessary change. We should update notify_customer_info_updated RPC. When called, it should fetch latest KYC using callback to business server (get /customer) and:
Update transaction status to
pending_customer_info_update
(NEEDS_INFO
);pending_anchor
(PROCESSING
);pending_user_transfer_start
(ACCEPTED
);error
(REJECTED
)We should add a new callback to send customer information. We can use /sep12 path in v2 and organize it better in v3
Slack discussion thread
Internal issue: ANCHOR-746
The text was updated successfully, but these errors were encountered: