Payment risk action nodes for graphs

What's new

Campaign, page, and segment-group graphs gain four action nodes for reacting to a risky payment:

• DeclinePaymentNode — declines the payment, with no retry.
• Require3DSNode — lets the capture through, but billing must re-run it with a 3DS challenge.
• BanUserNode — bans the player, which declines the payment too. Takes an optional reason stored on the player.
• BatchBanUserNode — bans every player in the game who shares the current player's value for ban_by_custom_attribute, such as a device or card ID. Nothing happens when the current player has no such attribute. Also takes an optional reason.

ban_by_custom_attribute is required on BatchBanUserNode. The other three carry only the usual node fields (id, x, y, title, description, next_node_id, break_on_error, result).

Impact

Fraud rules that previously only branched or notified can now act on the payment itself — decline it, force a 3DS challenge, or ban the player and everyone sharing their device or card.

Changes

Resource	Change
create_campaign, update_campaign	Added BanUserNode, BatchBanUserNode, Require3DSNode, and DeclinePaymentNode to the graph.nodes discriminator and oneOf
get_campaign_graph, update_campaign_graph	Added the four nodes to the graph nodes discriminator and oneOf
update_segment_group	Added the four nodes to the graph.nodes discriminator and oneOf
get_pages, get_page, create_page, update_page, bulk_update_page, translate_page	Added the four nodes to the DynamicBlock.graph_rules.nodes discriminator and oneOf

Upgrade

• No action required. To use a node, add an entry to the graph nodes map with the matching model_type — DeclinePaymentNode, Require3DSNode, BanUserNode, or BatchBanUserNode — plus ban_by_custom_attribute for the batch ban.
• Clients that validate graph responses against a generated model should regenerate, since these node types can now appear in nodes.

需要技术支持？
联系我们的集成技术团队： [email protected]