What transaction types does DPM support?

[jasonjudge]

It makes sense that DPM supports authorization and payments (authorization+caoture), but does it directly support any other transaction types?

The DPM documentation seems to imply that DPM does void, prior-authorized capture etc. but I suspect that part of the documentation is left over from the documentation from the other gateway methods that the DPM guide is obviously based on. The transaction types that do not involve user interaction to enter credit card details, are surely all done through the AIM method?

Is that right, or am I misunderstanding the documentation?

tl;dr: Authorization and authorization+capture (payment) is supported by DPM. For void, capture, credit (refund) you must use the AIM method. Correct?

-- Jason

[RaynorC1emen7]

It support all the transaction type, but like you said, it make sense to use AIM for some of them.

Also, you can try it with a test account.

[jasonjudge]

So by "support", what does that mean? When you do a DPM transaction, you are POSTing user-entered data from a form generated by your merchanent site direct to the Authorize.Net site. How does that even work for a VOID, where there is no user-entered data to POST?

Are you saying that you can POST a VOID from your merchant site, via the user's browser, in a secure way, and the VOID transaction request is responsed to by a callback from Authorise.Net to your merchant relay endpoint? That's how DPM works. Is that right? If so, when would you ever want to do that?

-- Jason

[RaynorC1emen7]

How does that even work for a VOID, where there is no user-entered data to POST?

The same way you post any data

<input  /> it could be hidden

Are you saying that you can POST a VOID from your merchant site, via the user's browser, in a secure way, and the VOID transaction request is responsed to by a callback from Authorise.Net to your merchant relay endpoint? That's how DPM works. Is that right?

It post to the same HTTPS url. Yes if you use DPM, it would use relay response.

If so, when would you ever want to do that?

I just saying is possible. it might not make any sence but possible.

[jasonjudge]

When I said "support" I guess I wasn't being clear what I meant. I realise that any interaction that the backend can have with a service, can be done using sofware that runs in a browser too. But there is some information that must not be exposed to the end user, bacause security relies on the third parties not having access to that information, and not being able to manipulate that information in transit.

So with that in mind, if a protocol cannot be run through the browser without exposing security-sensitive details, then so far as I am concerned, it is NOT "supported". We do secure stuff, and not unsecure stuff, even if it technically appears to work.

Does that change the answer in any way?

I'm still coming at this from the POC that the DPM documentation says that VOID (for example) is one of the actions that DPM provides, but I am not convinced. I believe I'm misreading the documentation, which I am perfectly happy to accept, or it is plain wrong and makes no sense and should probably not be in the documentation. I'm just really unsure which one it is.

-- Jason

[RaynorC1emen7]

Does that change the answer in any way?

Maybe you should tell us why you think wouldn't be secure

DPM still reqired x_fp_hash, x_fp_sequence,x_fp_timestamp 

I guess the best way to find out is test it on a test account.

[jasonjudge]

I've just spotted that the DPM documentation has been withdrawn a couple of days ago. DPM is now mentioned in an appendix in the SIM guide. That specifically states that DPM and SIM are identical, except for a few fields on the payment form. The payment form is only relevant when the customer is entering credit card details, and that only happens for authrorize and authorize+capture transactions.

So there you go, there is no such thing as VOID DPM (which answers my question), because DPM is SIM with some additional features, and SIM does not support VOID. VOID is supported by AIM only. Glad the guides have been cleared up.

DPM is just a way to move the credit card form from Authorize.Net to your own merchant site. The form still gets POSTed to the same place, where-ever the form is located. DPM allows you to turn off error reporting to the user on the Authorize.Net site (x_relay_always=true), so instead of presenting a form with an error message on Authorize.Net the user is taken back to your merchant site to correct errors on the form (assuming you have built that in). I have this working on a production site, and it works great for the end user.

The documentation still needs some correcting though, as it does not mention x_card_code in the direct POST form.

[RaynorC1emen7]

Sorry, should have told you to read the manual in the first place.

[jasonjudge]

I did read the manual. The manual contradicted itself. That is why I asked the question in the first place (and was very clear about that).

The manual has since been withdrawn. It is no longer on the site. It is gone. It is a dead manual, a deceased mamual, and not just sleeping. It is no more. It was wrong and confusing, as I suspected. That is why it has been taken off the site.

And that's fine :-)

[RaynorC1emen7]

You could also test it with a test account, the sandbox server is a replicate of the production server, it should act the same way, but without processing it thru a processor.