================================================================================

Dan,

Thanks.  Make sure to use the MID for this account:

Account MID: 2OhI269dkCqBVSJWgHhpIfG4LKs

Chris Benson, MDiv., BBehSc.
EVP- Sales & Business Development
O. 903-708-6422
C. 559-270-6422
chris@paynetworx.com
www.paynetworx.net

> Start new Ticket with email to Helpdesk@paynetworx.com

================================================================================

Hello,

I am Tom Kirby, a developer working for Dan Giacopelli at Ember/Skoop.

I'm using the AuthCapture api and there seems to have been a change in the acceptable values for POS EntryMode and Type since the last time I tested this api. 

Previously, these values worked:
EntryMode = "manual"
Type = "ecommerce"

This is for processing a user's credit card information directly, and tokenizing it for storage.

The documentation online indicates that the valid values for Type are Pos and Recurring, with Pos seemingly the correct choice. I have tried "pos", "Pos", "POS", and "".  

The pos variations result in this error:
Key: 'FrontEndRequest.POS.Type' Error:Field validation for 'Type' failed on the 'tran_type' tag

While the blank variation results in this error:
"selected initiation type or terminal type is incompatible with entry mode"
What is "initiation type"?
What is "terminal type"?


This is the entire request sent and response received:

AuthCapture request = Array
(
    [Amount] => Array
        (
            [Total] => 1.00
            [Tip] => 0.00
            [Fee] => 0.00
            [Tax] => 0.00
            [Shipping] => 0.00
            [Duty] => 0.00
            [Currency] => USD
        )

    [PaymentMethod] => Array
        (
            [Card] => Array
                (
                    [CardPresent] => 
                    [PAN] => Array
                        (
                            [PAN] => 5204730000001003
                            [ExpMonth] => 12
                            [ExpYear] => 25
                        )

                    [CVC] => Array
                        (
                            [CVC] => 321
                        )

                    [BillingAddress] => Array
                        (
                            [Name] => Thomas Kirby
                            [Line1] => 10286 Staples Mill Rd
                            [Line2] => Suite 162
                            [City] => Glen Allen
                            [State] => VA
                            [PostalCode] => 23060
                            [Country] => US
                            [Phone] => +18048827098
                            [Email] => tkirby@dynengsys.com
                        )

                )

        )

    [DataAction] => token/add
    [POS] => Array
        (
            [EntryMode] => manual
            [Type] => pos
            [Device] => NA
            [DeviceVersion] => NA
            [Application] => EmberPay
            [ApplicationVersion] => 1.0
            [Timestamp] => 2024-04-17T10:22:37-07:00
        )

    [Detail] => Array
        (
            [MerchantData] => Array
                (
                    [Transaction Type] => 
                    [CustomerID] => 804-882-7098
                )

        )

)

AuthCapture response = stdClass Object
(
    [TransactionID] => 2fEmLl4edZT1RI8kiZaUEw0uQcJ
    [EventID] => 2fEmLivDpQnSe6h5a2S13VFx9ct
    [RequestID] => 2fEmLooD3WvSOHu46jvqRnnZnBd
    [Error] => selected initiation type or terminal type is incompatible with entry mode
    [Approved] => 
)

================================================================================

I have a question regarding using micro-deposits to verify ach accounts. 
The article below describes a new requirement for such transactions.

"A Deep Dive into Nacha’s Micro-Entry Rule"
https://www.nacha.org/content/deep-dive-nachas-micro-entry-rule

"Originators must use “ACCTVERIFY” in the Company Entry Description field."

Paynetworx does not have a "Company Entry Description" field afaik, so where should we put "ACCTVERIFY" to be sure it lands where it should in the transaction?

We currently use the PaymentRelatedInformation field for the customer's address info.

Thank you,

Thomas Kirby