Charge method improvement

[danielneu]

Hi,

the charge method could also be used for convenience in case we see a soft decline (Order is suspenden => do not to a set call but do confirm and auth).
https://github.com/amzn/login-and-pay-with-amazon-sdk-php/blob/cbe6c69c0499d6b759b1dd468b302e3238068582/PayWithAmazon/Client.php#L1189

This will ease up the remedy workflow for merchants using this method.

Best wishes
Daniel

[shrakuma]

when it's a soft decline, the status is Suspended hence it won't go into the 'Draft' IF statement

when the ORO gets to 'Open' state calling charge method will go into
if ($oroStatus['State'] === 'Open') {} and makes the authorize call

[aaronrichmond]

Maybe we could add a ReCharge method/param... it would do a GetORO (see if Suspended) instead of Set, and then Confirm, Auth for existing oro's.

The Charge method could return to the calling method (which could be a javascript ajax call) to allow the front-end to message the customer easily, before a re-charge.

This could potentially be leveraged for auto-handling of declines for asynchronous or charge when ship, where the customer is notified after they've left the site there was an issue with payment.

Let's keep in the spirit of the updated SDKs and simplify the integration and prescribe the use cases. Handling declines is needed by all integrations.

[shrakuma]

@aaronrichmond I am getting confused here.

merchant calls charge method and then the ORO goes to suspended charge fails.
Merchant will request buyer to update the card. buyer updates the card after x amount of time.Then merchant will call the charge method again. this time it will pass because it's in open state.
the above scenario is already handled in the charge method

[danielneu]

@shrakuma
This is only true for the async workflow. Here we move the order to open again after the customer changed the payment method.

When talking about sync auth, the workflow is different.

• A merchant calls charge
• he receives a soft decline and re-displays the wallet widget
• the customer changes the payment method
• the merchant calls charge again

In this situation the ORO will still be suspended and we need to call confirm again, then authorize and capture.

@aaronrichmond I would go for the Charge method taking care of this. The big advantage is being able to keep your code untouched and simply call charge again. If we can do it in one place, we should avoid having all merchants implement it.

Hoping this explains it better.

~Daniel

[aaronrichmond]

@danielneu

The big advantage is being able to keep your code untouched and simply call charge again. If we can do it in one place, we should avoid having all merchants implement it.

Like this, good call. Merchant has less to think about regarding async / sync.

[shrakuma]

agreed. a simple IF statement will fix it

[islandskater43]

Adding an else if at line 1248 would enable us to check if the status of the ORO is suspended. If it is however, I don't think we should blindly call ConfirmOrderReference, but instead check for constraints. If no constraints exist, call ConfirmOrderReference and allow processing to continue. We could do the same at line 1282 for billing agreement support.

[vhpm18]

Good afternoon, a question does the sdk allow automatic charges? So there is a charge according to the plan or package that was previously sold to the user.
something like a SUBSCRIPTION