Working with payment states
This section explains how to work with payment states. The payment state machine is restricted by the API so that no new states or transitions can be added to it. However, it is possible to add related states to payment states.
For security reasons, the payment state machine is restricted. However, related states can be added to the payment states, which will cause the order state or the delivery state to change when a payment goes to a particular state. There is a working example in the Add a related state article.
Default implementation
The following example shows how the related states are added in the default implementation, which is in the PaymentStateBuilder class.
For example, when the payment is set to Paid, an attempt is made to set the order to Processing or Completed. In the default implementaiton of the order state machine the order will go to Processing if the delivery is not yet completed when the payment is Paid. If the delivery is already Completed when the payment is Paid. the order will go to Completed.
/// <summary>
/// Builds related transitions to payment state.
/// </summary>
/// <param name="stateManager">State transitions manager.</param>
internal virtual void BuildStateTransitions(StateTransitionsManager stateManager)
{
//..other code.
//If payment is completed, order state should be in either processing or completed.
stateManager.AddRelatedStateToPaymentState((short)PaymentStatus.Paid, FiniteStateMachineType.Order, (short)OrderState.Processing);
stateManager.AddRelatedStateToPaymentState((short)PaymentStatus.Paid, FiniteStateMachineType.Order, (short)OrderState.Completed);
//..other code
}