Any Changes to Subscription Merchant ID API or Display?

API Q&A
1

We use the PHP iSDK to add subscription orders which often have a different merchant ID than the primary order, if that matters. We are being told that the subscriptions in Infusionsoft do not have a merchant account selected in their drop-down. Could this be a display issue on the Infusionsoft side or is there something that needs to change in our API call. Examples below, thanks.

API call being used:

$this->infusionsoftApp->addRecurring((int)$contactId, false, (int)$subscriptions[$i][‘subId’], (int)$subscriptionMerchantId, (int)$creditCardId, 0, (int)$subscriptions[$i][‘days’]);

Screen grab of what is seen in Infusionsoft:

PleaseSelectAMerchantAccount

2

Hi,
I do know that if you are selecting the default merchant account on a subscription it will show the “Please select merchant account” option but everything should still work as expected using the default. Unless something has recently change it should be selecting the option for the correct merchant account Id provided. I did test this on my own application and providing a merchant account other than the default does set the drop down value as expected.

3

Here’s a small update on this issue, it appears to be a display issue on the web form. I was able to query the RecurringOrder table after using the iSDK addRecurring call which returned the proper merchantAccountId. However, when viewing the subscription record in Infusionsoft it still shows “Please select a merchant account”. We also believe this issue to have cropped up on the evening of October 17th if that’s of any help pinning down the cause.

Here is the XML-RPC payload and subsequent query result from the RecurringOrder table:

<?xml version="1.0"?> InvoiceService.addRecurringOrder **** 14 0 4 2 56 0 120

Array
(
[0] => Array
(
[MerchantAccountId] => 2
[Status] => Active
[ContactId] => 14
)
)

4

Another update, I’m being informed it is more than a display issue. A test subscription that triggered today (10/30) did not charge. However, I can pull what appears to be valid data using both the legacy and REST APIs:

Legacy:
(
[MerchantAccountId] => 60
[Status] => Active
[BillingCycle] => 6
[PaymentGatewayId] => 60
[LastBillDate] => 20181030T00:00:00
[BillingAmt] => 0.1
[AutoCharge] => 1
[Frequency] => 1
[PaidThruDate] => 20181030T00:00:00
[NextBillDate] => 20181031T00:00:00
)

REST:
{
“id”: *,
“quantity”: 1,
“active”: true,
“contact_id”: *,
“product_id”: *,
“subscription_plan_id”: *,
“billing_amount”: 0.1,
“auto_charge”: true,
“billing_frequency”: 1,
“billing_cycle”: “DAY”,
“start_date”: “2018-10-29”,
“next_bill_date”: “2018-10-31”,
“end_date”: null,
“payment_gateway_id”: 60,
“credit_card_id”: *,
“use_default_payment_gateway”: true
}

They both appear to have valid IDs for the payment gateway. One difference is the inclusion of a “use default payment gateway” flag, which is not present in the legacy API that I could see.

Thanks in advance for any insight.

5

Hey,

I wanted to let you know that I have done some testing around adding subscriptions and have not been able to duplicate this particular problem exactly. If you know specific steps that you are taking that is causing this problem then perhaps I can try to follow those precisely. I did want to mention that around the time that you posted there was an issue that possibly caused some of the problems you are seeing. When creating a subscription some data was not being properly set and I’m wondering if this is related to bad data caused by said issue.

I would suggest to keep a keen eye on this and see if you are seeing new subscription records also having the same problem. If that is the case please record each step of your process and get in contact with our support team. They should be able to look at the data for the given subscriptions experiencing the problem as well as follow your process to recreate the issue and subsequently create defect ticket.

6

Hi Sterling,

Thank you for doing some testing, much appreciated. We will see if support can figure out what’s going on.

7

In case anyone in the future has a similar issue, I believe I have it fixed. I can’t say exactly what changed on 10/17/18 on the Infusionsoft side, but it appears the update call (dsUpdate) that gets run after the recurring order call (addRecurring) was somehow effected. I haven’t done enough testing to determine if any dsUpdate calls to the RecurringOrder table would cause this or if it was just the specific call we were making.

Here is basically what the code was doing:

$recurringOrderId = addRecurring(blah blah);

dsUpdate(“RecurringOrder”, $recurringOrderId, array(
‘_originId’ => $orderId
));

For now, I’ve simply removed the dsUpdate call as it seemed to just be some relic of the past that no longer was needed anyway.

I want to be clear that the integration code used to communicate with the Infusionsoft XML-RPC API, including the above calls was not altered on 10/17 so I’m not sure what changed. That being said, our integration is quite old and makes use of a very old version of the PHP iSDK which I’m guessing doesn’t help things.

Thanks

8

Just so others are aware, I also ran into a similar problem this morning. After doing a bit of digging it appears that just like @Great_Falls said, the API was returning correct values for the MerchantAccountId but the UI on InfusionSoft was not. And that whatever the problem is, it is more than a display bug and is affecting the ability of subscriptions to create new invoices and charge.

We were able to consistently find a problem with recurring orders that were updated with new credit card information, where our update call looked like this:

api.perform 'DataService.update', 'RecurringOrder', order.id, {'CC1' => cc.id}

The fix that seems to work for us is to add the MerchantAccountId into the attributes to update, so the call will look like this:

api.perform 'DataService.update', 'RecurringOrder', order.id, {'CC1' => cc.id, 'MerchantAccountId' => order.merchant_account_id}

I update all of our recurring orders that were updated after 10/17/2018, based on the timeframe @Great_Falls gave, so hopefully we won’t run into this issue again. Obviously, the true fix would be for IFS to not lose the MerchantAccountId in the first place.

InfusionSoft: Any idea on when we can expect this bug to be fixed?

9

We are having the exact same issue. Just like @ STEVE_IANNOPOLLO said, we noticed when our users would update their credit cards on their subscriptions. We are doing the same work around, but this is a pretty serious issue because it prevents orders from being processed.