Category Archives: General

Payflow link invalid input errors

If you are a playflow link merchant and you recently started having “Invalid input” errors from your payment pages, check the source of your form that submits the data to payflow link. Sometime recently (May or June 2013) Payflow began rejecting HTML tags in form field input. I had a “<BR>” tag in my description field, and users were being kicked out with an “invalid input” error.

Android poor battery life, Exchange Services

I had a new Android phone the other day, fresh out of the box; set up my hosted exchange account, and my battery life was measured in hours (as in 5-6 hours). The phone was getting hot all the time and the data arrows were constantly lit. Stopping “sync” or preventing email from syncing in settings solved it, but obviously that’s not a tenable solution for a mobile device.

I logged into OWA and sent logs to myself between the phone and the Exchange server. Over the course of a few minutes there were more than 60 of these:


SyncCommand_OnExecute_Exception :
Microsoft.Exchange.AirSync.AirSyncPermanentException
at Microsoft.Exchange.AirSync.RecipientInfoCacheSyncCollection.OpenSyncState(Boolean autoLoadFilterAndSyncKey, SyncStateStorage syncStateStorage)
at Microsoft.Exchange.AirSync.SyncCommand.SyncTheCollection(SyncCollection collection, Boolean createSubscription, Boolean tryNullSync)
at Microsoft.Exchange.AirSync.SyncCommand.OnExecute()

LogicalRequest :
<?xml version="1.0" encoding="utf-8" ?>
<Sync xmlns="AirSync:">
<Collections>
<Collection>
<SyncKey>613780178</SyncKey>
<CollectionId>RI</CollectionId>
<DeletesAsMoves/>
<GetChanges/>
<WindowSize>10</WindowSize>
<Options/>
</Collection>
</Collections>
</Sync>

Command_WorkerThread_Exception :
--- Exception start ---
Exception type: Microsoft.Exchange.AirSync.AirSyncPermanentException
Exception message:
Exception level: 0
HttpStatusCode: OK
AirSyncStatusCode: Search_TooComplex
XmlResponse:
<?xml version="1.0" encoding="utf-8" ?>
<Sync xmlns="AirSync:">
<Status>8</Status>
</Sync>
Exception stack trace:    at Microsoft.Exchange.AirSync.SyncCommand.OnExecute()
at Microsoft.Exchange.AirSync.SyncCommand.ExecuteCommand()
at Microsoft.Exchange.AirSync.Command.WorkerThread()
Inner exception follows...
Exception type: Microsoft.Exchange.AirSync.AirSyncPermanentException
Exception message:
Exception level: 1
HttpStatusCode: InternalServerError
AirSyncStatusCode: ServerError
XmlResponse:
[No XmlResponse]
Exception stack trace:    at Microsoft.Exchange.AirSync.RecipientInfoCacheSyncCollection.OpenSyncState(Boolean autoLoadFilterAndSyncKey, SyncStateStorage syncStateStorage)
at Microsoft.Exchange.AirSync.SyncCommand.SyncTheCollection(SyncCollection collection, Boolean createSubscription, Boolean tryNullSync)
at Microsoft.Exchange.AirSync.SyncCommand.OnExecute()
--- Exception end ---

AccessState :
Allowed

AccessStateReason :
Global

ResponseHeader :
HTTP/1.1 200 OK

ResponseBody :
<?xml version="1.0" encoding="utf-8" ?>
<Sync xmlns="AirSync:">
<Status>8</Status>
</Sync>

These errors were coming in at the rate of 1 per second, which explains why my phone was hot to the touch.

The solution (for me) was to delete the Exchange account from the phone, delete the phone from OWA, and redo the partnership. If it makes any difference, this time I selected “All” for the length of time to download emails, and I chose manual setup instead of Autodiscover setup. Everything is working normally now.

1099-K and transaction date or settlement date

I believe I’ve uncovered an accounting nightmare for merchants who receive 1099-Ks. I noticed that some of my monthly totals for 1099-K were off by small amounts vs. my (very) detailed monthly accounting. Turns out, the 1099-K’s appear to have been generated based on transaction date, while my reporting is traditionally based on settlement date (i.e., the date the merchant receives the money).

I would consider the settlement date to be the constructive date of receipt, because that is the date the money is transferred to my account. However, the credit card processors are handling this based on transactional data, which causes irregularities because all my bank statements show the income in the subsequent month.

Since it is not possible for a merchant to make such a logical point to the IRS and be understood, the only solution appears to be to edit the dates of the offending transactions to reflect the month (and year) reported by the 1099-K.

Way to go, people.

Apache: “couldn’t create child process: 720005”

If you installed Apache on Windows (I like WAMPServer myself) and you’re trying to run Perl scripts, you might encounter the dreaded Internal Server Error (500) and a cryptic entry in Apache’s error log:

[Sat Jun 04 19:01:50 2011] [error] [client 127.0.0.1] (OS 2)The system cannot find the file specified. : couldn't create child process: 720002:
[Sat Jun 04 19:01:50 2011] [error] [client 127.0.0.1] (OS 2)The system cannot find the file specified. : couldn't spawn child process:

I realized I had installed ActivePerl to the wrong place, and Apache couldn’t find it (I was able to run my Perl scripts from the command line, just not from Apache). All my perl scripts start with #!/usr/local/bin/perl as the shebang line, since this is what my Linux servers all use. So on Windows, I always install ActivePerl to c:\usr\local and it works great. My earlier mistake was to install ActivePerl to c:\usr\local\perl. So by removing and reinstalling ActivePerl to the correct directory, I thought this would be solved.

Then I was getting:

[Sun Jun 05 07:29:24 2011] [error] [client 127.0.0.1] (OS 5)Access is denied. : couldn't create child process: 720005:
[Sun Jun 05 07:29:24 2011] [error] [client 127.0.0.1] (OS 5)Access is denied. : couldn't spawn child process:

Now I was scratching my head. Access denied? Turns out, even though I had uninstalled and reinstalled ActivePerl to c:\usr\local, there was still a “perl” folder inside c:\usr\local\bin from the earlier installation of ActivePerl. Of course my scripts are looking for \usr\local\bin\perl – so they are finding the FOLDER called “perl” rather than the executable, perl.exe. You can’t execute a folder, hence the access denied error. Once I deleted the erroneous folder, the shebang lines in my scripts directed Apache to the perl executable and my script started working immediately.

So, if you are seeing this error, look very closely at your shebang lines and where they point to. In my case, uninstalling ActivePerl did not fully remove the prior directory structure and that caused problems even when I later reinstalled it to the correct place.